Well, maybe this is a good enough argument to give up. If the best we can say is that having a bytes and a str as keys *may* cause a TypeError on lookups, I'm not sure it is worth it to try to raise the probability that it'll actually be raised...
--Guido On 9/28/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 9/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 9/27/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > > > > Should a TypeError be raised as soon as you try to put a bytes and a > > > string in the same dict, even if they don't happen to hash equal? > > > Good idea, if you can figure out a way to implement this efficiently. > > In news that may surprise no one, there were corner cases... > > (1) Does it have to raise the TypeError eagerly in all cases, or is > it OK to do so only when its easy? > > For example, would it be OK to stop verifying once some keys have been > deleted? > > (2) Is the restriction "sticky" for a dict, or based on current contents? > > Current contents makes sense, but ... > > If code clears an existing dict rather than creating a new one, then > that specific dict is probably a communication channel, and the API > should specify whether it takes bytes or characters. > > -jJ > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
