[Python-3000] bytes and dicts (was: PEP 3137: Immutable Bytesand Mutable Buffer) (original) (raw)

Michael Urman murman at gmail.com
Sat Sep 29 17:12:06 CEST 2007

On 9/29/07, Guido van Rossum <guido at python.org> wrote:

On 9/29/07, Phillip J. Eby <pje at telecommunity.com> 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

More information about the Python-3000 mailing list