"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | | Well, if we wanted "x" and b"x" to compare unequal instead of raising | an exception, we could just define it that way (it was that way until | just before 3.0a1). But we're explicitly defining it to raise a | TypeError so as to catch buggy code. I think trying to fix dict lookup | so that it, and only it, treats this as unequal, would be adding too | many quirks. | | We could choose to kill the TypeError altogether. If we keep it, we | should consistently let it raise TypeError everywhere. | | The question is whether it's worth the effort to raise TypeError when | the *potential* exists that a certain hash sequence *could* raise this | TypeError. I'm less and less convinced -- after all, we're making the | exception only for bytes/str, not for other types that might raise | TypeError upon comparison. | | So, I think that after all this was a bad idea. Sorry.
If you mean making a special case exception for string/bytes equality test, I agree. Would a restricted key dict (say, rdict, in collections) solve the problem you are aiming at? import collections adict = rdict(str) bdict = rdict(bytes) Now any buggy insertions get caught. Terry J. Reedy _______________________________________________ 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
