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

[Michael Urman]

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