On 9/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/29/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > I'm coming into this thread a little bit late, but if we don't want > > strings and bytes to be comparable, shouldn't we just make them > > *unequal*? I mean, under normal circumstances, == and != are > > available on all objects without causing errors, and the same > > TypeError would occur for things like list.remove(). > > Until just before 3.0a1, they were unequal. We decided to raise > TypeError because we noticed many bugs in code that was doing things > like > > data = f.read(4096) > if data == "": break
I agree that it's nice to catch this sort of error early, but I'm wondering how to reconcile this decision with the discussion we had a year ago when dicts stopped suppressing comparison exceptions. http://mail.python.org/pipermail/python-dev/2006-August/068090.html is the beginning of the thread, and http://mail.python.org/pipermail/python-dev/2006-August/068112.html is a clear description of an __eq__ raising an exception as being buggy. If we're going to take a PBP approach to letting bytes() == str() raise an exception, is there a PBP factor to having dictionaries cover for this exception? The only unpredictable thing I see is if you're willy-nilly mixing bytes and strs and expecting to be able to lookup one with the other. If you're instead trying to store both, much like you can store strs and tuples, this shouldn't cause a problem. Even if it doing so is weird. The idea of if "" in somedict: pass raising a TypeError depending on the values in somedict is not pleasant. Just to throw another idea out there, would a variant of dict that suppresses these comparison exceptions, say collections.loosedict, sidestep the issue? -- Michael Urman _______________________________________________ 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
