[Python-Dev] Problems with GeneratorExit deriving from Exception
Hi, (I was asked to forward this from the bug tracker) > We have also run into problems where a task tries to "return" (yield Return()) > from within a try: except Exception: block. Since returning from a coroutine > is > roughly equivalent to "raise GeneratorExit", the exception can be caught and > ignored, with the same consequences as above. I may be missing something but why don't you just catch StandardError instead? If I believe Python 2.5's exception hierarchy it would catch anything under Exception except for GeneratorExit, StopIteration and the various Warnings. Also it seems to me that muting any Exception is bad practice since it can lead you to overlook errors in your code. It's better to catch a specific Exception subclass, like IOError (or XMLRPCError, or whatever it is called). Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with GeneratorExit deriving from Exception
Guido van Rossum wrote: > Well argued. I suggest to go for option (1) -- make GeneratorExit > inherit from BaseException. We can do this starting 2.6. Feel free to > upload a patch to bugs.python.org. It actually took me a while to figure out why this use case was convincing, when the same idea had been rejected for 2.5. For anyone else as slow as me: in the hypothetical examples I posted before the release of 2.5, the yield could be moved to an else clause on the try-except statement without adversely affecting the semantics. The use case Chad presented here is different, because the exceptions to be handled are being passed back in via the yield expression - moving it would defeat the whole purpose of the exception handling. I'm sure the fact that the example comes from a real application rather than the 'what-if' generator in my brain helps a lot too :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to PEP 366 (Relative imports from the main module)
Guido van Rossum wrote: > This looks good. Please make the appropriate changes to the PEP and to > PEP 0 to mark it as accepted. I should get to that in the next day or two. Thanks. > I think the implementation is fine too (others will have to check it > more carefully) but I noticed that the promised functionality of -m > doesn't work yet It turns out one of the code paths through runpy wasn't getting tested properly, and naturally it was the path that the -m switch relies on. I've posted a new patch which both fixes that code path and adds additional tests to make sure it is doing the right thing. Cheers, Nick. PEP 366 implementation patch (http://bugs.python.org/issue1487) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal news: speedup and stabilization
Facundo Batista wrote: > 2007/11/24, Nick Coghlan <[EMAIL PROTECTED]>: > >> Did you change the Decimal repr to use the same format for the mantissa? > > I don't understand the question. The output of repr() does not show > this internals... Yeah, um... can we just forget I asked that question? (I blame lack of sleep, or coffee, or something...) >> Could you also check the performance gain against the telco benchmark >> which is in the sandbox? [1] > > I tested different versions of Decimal with this telco.py. > > With Python from the trunk (r58550), which is the last decimal.py > version previous to this change: 1241.8 > > After changed it to keep _int as string: 869.3 (30% faster!) > > But still there're a lot of room for improvements. I just commited > other patch from Mark, where he reordered __new__, to minimize > isinstance() checks for the most used types.} > > After new reordering patch: 672.9 (22% faster!) Great news! Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Fred Drake wrote: > I suspect that's indistinguishable from everyone being tired of the > discussion, knowing that you're going to pick something reasonable in > spite of our yammering. What Fred said. It's Guido's bikeshed, he can choose the colour :) Just for the record, I also like the idea of __builtins__ being a magic alias for the boringly-but-practically named builtins module. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with GeneratorExit deriving from Exception
Antoine Pitrou schrieb: > Hi, > > (I was asked to forward this from the bug tracker) > >> We have also run into problems where a task tries to "return" (yield >> Return()) >> from within a try: except Exception: block. Since returning from a >> coroutine is >> roughly equivalent to "raise GeneratorExit", the exception can be caught and >> ignored, with the same consequences as above. > > I may be missing something but why don't you just catch StandardError > instead? If I believe Python 2.5's exception hierarchy it would catch > anything under Exception except for GeneratorExit, StopIteration and the > various Warnings. Problem is, many (most?) third-party modules derive their exceptions from Exception, not StandardError, so you'd have to add special cases for them too. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-string keys in namespace dicts
On 2 Dec 2007, at 03:09, Neil Toronto wrote: > Are there any use-cases for allowing namespace dicts (such as globals, > builtins and classes) to have non-string keys? I'm asking because I'm > planning on accelerating method lookups next, and the possibility of a > key compare changing the underlying dict could be a major pain. (It > was > a minor pain for globals.) The only plausible use case I can think of might be wanting to use ints or longs as keys, though I've never seen it done. Of course this would be trivial to code around and it seems very much a fringe case, so I'd be in favour of deprecating non-string namespace keys if it's going to make look-ups go faster. Cheers, Nicko ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with GeneratorExit deriving from Exception
Hi Antoine, Antoine Pitrou wrote: > Hi, > > (I was asked to forward this from the bug tracker) > >> We have also run into problems where a task tries to "return" (yield >> Return()) >> from within a try: except Exception: block. Since returning from a >> coroutine is >> roughly equivalent to "raise GeneratorExit", the exception can be caught and >> ignored, with the same consequences as above. > > I may be missing something but why don't you just catch StandardError > instead? If I believe Python 2.5's exception hierarchy it would catch > anything under Exception except for GeneratorExit, StopIteration and the > various Warnings. If socket.error, xmlrpclib.Fault, httplib.HTTPException, etc. all extended StandardError, then we would probably be fine with that approach. But I think the majority of exceptions, both in the standard library and our code, extend Exception directly. > Also it seems to me that muting any Exception is bad practice since it > can lead you to overlook errors in your code. It's better to catch a > specific Exception subclass, like IOError (or XMLRPCError, or whatever > it is called). Yes, in general, it's better to catch specific errors, but sometimes it really is the case that it doesn't matter why the call failed, as long as your unit and acceptance tests verify that the code behaves as expected and you log any exceptions that do occur. In fact, our logger remembers the last N error or exception log entries and automatically sends them back to our servers for analysis. So think of it as protecting the application from intermittent failures rather than silently dropping exceptions. :) Chad ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Dec 2, 2007 7:40 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Just for the record, I also like the idea of __builtins__ being a magic > alias for the boringly-but-practically named builtins module. [Imagine me jumping up and down and screaming at the top of my lungs out of frustration:] BUT THAT'S NOT WHAT IT IS! IT'S A HOOK FOR SANDBOXING! YOU SHOULD NEVER BE USING __builtins__ DIRECTLY EXCEPT WHEN CONTROLLING THE SET OF BUILTINS AVAILABLE TO UNTRUSTED CODE! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with GeneratorExit deriving from Exception
On Dec 2, 2007 11:29 AM, Chad Austin <[EMAIL PROTECTED]> wrote: > Hi Antoine, > > Antoine Pitrou wrote: > > Hi, > > > > (I was asked to forward this from the bug tracker) > > > >> We have also run into problems where a task tries to "return" (yield > >> Return()) > >> from within a try: except Exception: block. Since returning from a > >> coroutine is > >> roughly equivalent to "raise GeneratorExit", the exception can be caught > >> and > >> ignored, with the same consequences as above. > > > > I may be missing something but why don't you just catch StandardError > > instead? If I believe Python 2.5's exception hierarchy it would catch > > anything under Exception except for GeneratorExit, StopIteration and the > > various Warnings. > > If socket.error, xmlrpclib.Fault, httplib.HTTPException, etc. all extended > StandardError, then we would probably be fine with that approach. But I think > the majority of exceptions, both in the standard library and our code, extend > Exception directly. Note that StandardError was removed from py3k. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Guido van Rossum schrieb: > On Dec 2, 2007 7:40 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> Just for the record, I also like the idea of __builtins__ being a magic >> alias for the boringly-but-practically named builtins module. > > [Imagine me jumping up and down and screaming at the top of my lungs > out of frustration:] > > BUT THAT'S NOT WHAT IT IS! IT'S A HOOK FOR SANDBOXING! YOU SHOULD > NEVER BE USING __builtins__ DIRECTLY EXCEPT WHEN CONTROLLING THE SET > OF BUILTINS AVAILABLE TO UNTRUSTED CODE! You've scared me. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] blocking a non-blocking socket
An interesting question has come up in the development of the SSL module. The function ssl.wrap_socket() takes a flag, do_handshake_on_connect, which tells it whether to do the SSL handshake before returning an SSLSocket object to the caller. If the socket being wrapped is non-blocking, the code in wrap_socket() must invoke do_handshake() multiple times, and effectively block until the handshake is done. Right now, I'm doing it with this loop: if do_handshake_on_connect: # have to loop to support non-blocking sockets while True: try: self.do_handshake() break except SSLError, err: if err.args[0] == SSL_ERROR_WANT_READ: select.select([self], [], []) elif err.args[0] == SSL_ERROR_WANT_WRITE: select.select([], [self], []) else: raise But this seems fragile to me. "select" and/or "poll" is awfully system-dependent. What I'd like to do is just use the socket API, something like: blocking = self.getblocking() try: self.setblocking(1) self.do_handshake() finally: self.setblocking(blocking) But there's no "getblocking" method on sockets. Instead, there's "gettimeout". So I'd write something like timeout = self.gettimeout() try: self.setblocking(1) self.do_handshake() finally: if (timeout == 0.0): self.setblocking(0) But my mother taught me never to test for equality against floating-point zero. But in this case it might just fly... Or, should I just set the timeout: timeout = self.gettimeout() try: self.settimeout(None) self.do_handshake() finally: self.settimeout(timeout) This is the solution I'm leaning towards... Any recommendations? Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] blocking a non-blocking socket
On Sun, Dec 02, 2007 at 12:23:01PM -0800, Bill Janssen wrote: [skip] > Or, should I just set the timeout: > > timeout = self.gettimeout() > try: > self.settimeout(None) > self.do_handshake() > finally: > self.settimeout(timeout) Yes, this is the correct solution for all cases: if the timeout is None (socket is blocking) or 0 (non-blocking) or not-0 (blocking with timeout) - just set it back. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] StandardError removed from py3k
Le dimanche 02 décembre 2007 à 12:08 -0800, Neal Norwitz a écrit : > Note that StandardError was removed from py3k. Out of curiosity, what is the reason for this? Another exception tree rearrangement? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with GeneratorExit deriving from Exception
Le dimanche 02 décembre 2007 à 11:29 -0800, Chad Austin a écrit : > If socket.error, xmlrpclib.Fault, httplib.HTTPException, etc. all extended > StandardError, then we would probably be fine with that approach. But I > think > the majority of exceptions, both in the standard library and our code, extend > Exception directly. Ok, understood. :) To me it's a shame people don't try to make their exceptions inherit from a proper base class (be it IOError, ValueError, etc.), but anyway... cheers Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-string keys in namespace dicts
Nicko van Someren wrote: > On 2 Dec 2007, at 03:09, Neil Toronto wrote: > >> Are there any use-cases for allowing namespace dicts (such as globals, >> builtins and classes) to have non-string keys? I'm asking because I'm >> planning on accelerating method lookups next, and the possibility of a >> key compare changing the underlying dict could be a major pain. (It was >> a minor pain for globals.) > > The only plausible use case I can think of might be wanting to use ints > or longs as keys, though I've never seen it done. Of course this would > be trivial to code around and it seems very much a fringe case, so I'd > be in favour of deprecating non-string namespace keys if it's going to > make look-ups go faster. If you insert non-string keys into a namespace dict it'll slow down lookups already. :) The dict will switch to the more general lookdict from lookdict_string. Looks like it's just a bad idea all around. It turned out not *that* hard to code around for attribute caching, and the extra cruft only gets invoked on a cache miss. The biggest problem isn't speed - it's that it's possible (though extremely unlikely), while testing keys for equality, that a rich compare alters the underlying dict. This causes the caching lookup to have to try to get an entry pointer again, which could invoke the rich compare, which might alter the underlying dict... This problem already exists for general dicts with non-string keys (it can blow the C stack) and attribute caching makes it a bit more likely (the compare only has to insert or delete an item rather than cause a resize), so it'd be nice if it didn't apply to identifiers. As far as I know, though, the only way to get non-string keys into a class dict is by using a metaclass. Anyway, report: I've got an initial working attribute cache, using the conveniently-named-and-left-NULL tp_cache. It's a nice speedup - except on everything the standard benchmarks test, because their class hierarchies are very shallow. :p If an MRO has more than two classes in it, every kind of lookup (class method, object method, object attribute) is faster. Having more than four or five makes things like self.variable take less than half the time. It'd be nice to have a benchmark with a deep class hierarchy. Does anybody know of one? I'm working on making it as fast as the original when the MRO is short. Question for Guido: should I roll this into the fastglobals patch? Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-string keys in namespace dicts
On Sun, Dec 02, 2007, Neil Toronto wrote: > > Anyway, report: I've got an initial working attribute cache, using the > conveniently-named-and-left-NULL tp_cache. It's a nice speedup - except > on everything the standard benchmarks test, because their class > hierarchies are very shallow. :p If an MRO has more than two classes in > it, every kind of lookup (class method, object method, object attribute) > is faster. Having more than four or five makes things like self.variable > take less than half the time. This patch is probably a non-starter, then: that's what killed the CACHE_ATTR patch several years ago (I was sprinting on that with Guido and Ping): http://mail.python.org/pipermail/python-dev/2007-June/073604.html -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with GeneratorExit deriving from Exception
On Dec 1, 2007 11:14 PM, Chad Austin <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On Dec 1, 2007 2:38 PM, Chad Austin <[EMAIL PROTECTED]> wrote: > >> This problem could be solved in several ways: > >> > >> 1) Make GeneratorExit derive from BaseException, just like SystemExit. > > > > Well argued. I suggest to go for option (1) -- make GeneratorExit > > inherit from BaseException. We can do this starting 2.6. Feel free to > > upload a patch to bugs.python.org. > > Great! Patch is uploaded at http://bugs.python.org/issue1537 > > The patch changes the definition of GeneratorExit so that it extends > BaseException, adds a generator test, updates exception_hierarchy.txt, and > updates the exceptions page in the documentation. This is my first patch to > Python -- did I miss anything? I have not looked at the patch, so take what I say with a grain of salt. =) First, a generator test is not necessary. The patch changes the inheritance of exceptions, nothing more. While its usefulness is manifested for generators, this is really an exception detail. And changing exception_hierarchy.txt gives you the exception test you need. Second, the docs will need to be changed. I know that Doc/library/exceptions.rst needs a tweak. Not sure if anywhere else does. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] StandardError removed from py3k
Antoine Pitrou schrieb: > Le dimanche 02 décembre 2007 à 12:08 -0800, Neal Norwitz a écrit : >> Note that StandardError was removed from py3k. > > Out of curiosity, what is the reason for this? Another exception tree > rearrangement? I think it was found not to serve a real purpose. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] StandardError removed from py3k
On Dec 2, 2007 1:49 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Antoine Pitrou schrieb: > > Le dimanche 02 décembre 2007 à 12:08 -0800, Neal Norwitz a écrit : > >> Note that StandardError was removed from py3k. > > > > Out of curiosity, what is the reason for this? Another exception tree > > rearrangement? > > I think it was found not to serve a real purpose. > That's right. Since we introduced BaseException StandardException was no longer needed. -Brett > Georg > > -- > Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. > Four shall be the number of spaces thou shalt indent, and the number of thy > indenting shall be four. Eight shalt thou not indent, nor either indent thou > two, excepting that thou then proceed to four. Tabs are right out. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-string keys in namespace dicts
Neil Toronto wrote: > It'd be nice to have a benchmark with a deep class hierarchy. Does > anybody know of one? Zope has some very complex and deep class hierarchies, especially when it comes down to Plone and Archetypes. Unfortunately Zope is still stuck with Python 2.4. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] blocking a non-blocking socket
Bill Janssen wrote: > What I'd like to do is just use the socket API, > something like: > > blocking = self.getblocking() > try: > self.setblocking(1) > self.do_handshake() > finally: > self.setblocking(blocking) I'm not sure this is the right approach. If the calling code has made the socket non-blocking, then it doesn't want any operations on it to block. Rather than temporarily making it blocking by whatever means, some indication needs to be returned that the operation would block, and a way provided for the calling code to re-try later. If that can't reasonably be done, then passing a non-blocking socket here should be an error. > But my mother taught me never to test for equality against > floating-point zero. That doesn't apply here. If a float is explicitly set to 0.0 you can reasonably expect it to test equal to 0.0. The caveat only applies to results of a calculation, which may incorporate roundoff errors. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] blocking a non-blocking socket
> Rather than temporarily > making it blocking by whatever means, some indication needs > to be returned that the operation would block, and a way > provided for the calling code to re-try later. > > If that can't reasonably be done, then passing a non-blocking > socket here should be an error. I tend to agree with you. At this point, we're executing bad code, because passing in a non-blocking socket and asking the routine to do the handshake is self-contradictory. Checking for this condition and raising an exception would probably be best. Other opinions. > > But my mother taught me never to test for equality against > > floating-point zero. > > That doesn't apply here. If a float is explicitly set to 0.0 > you can reasonably expect it to test equal to 0.0. The caveat > only applies to results of a calculation, which may incorporate > roundoff errors. Yep. Sorry, meant to imply that with the next sentence. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-string keys in namespace dicts
At 08:09 PM 12/1/2007 -0700, Neil Toronto wrote: >Are there any use-cases for allowing namespace dicts (such as globals, >builtins and classes) to have non-string keys? Yes. See http://pypi.python.org/pypi/AddOns > I'm asking because I'm >planning on accelerating method lookups next, and the possibility of a >key compare changing the underlying dict could be a major pain. (It was >a minor pain for globals.) For what it's worth, the AddOns package recommends the use of instances of built-in types (or tuples thereof) as add-on keys, so they would not have that problem in normal use. I don't see a problem with requiring dictionary key comparisons to be side-effect-free - even in the general case of dictionaries, not just namespace ones. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
