[Python-Dev] Dict suppressing exceptions (original) (raw)

Michael Urman murman at gmail.com
Thu Aug 10 15:48:43 CEST 2006

On 8/10/06, M.-A. Lemburg <mal at egenix.com> wrote:

Guido van Rossum wrote: > But since people are adamant that they want this in sooner, I suggest > that to minimize breakage we could make an exception for str-unicode > comparisons. > What do people think?

I'd suggest that we still inform the programmers of the problem by issuing a warning (which they can then silence at will), maybe a new PyExcUnicodeWarning. BTW, in Py3k, this case would not trigger at all, since all text would be Unicode and bytes wouldn't be comparable to Unicode anyway. However, that's a different discussion which we can have after Python 2.5 is out the door.

I strongly believe that unicode vs str here is the symptom and not the actual problem. The comparison between two non-us-ascii str/unicode instances is but one of many ways to raise an exception during comparison. It's not even obvious ahead of time when it will occur. Try my example below with (sys.maxint << 1) and -2 instead of 1 and 1. Do you expect a problem?

Because str/unicode is the common case, we saw it first. If we address the symptom instead of the problem, someone will be complaining within a years time because they have a class that they mix in with other items for a function handler lookup, or who knows what, that works like the following:

class hasher(object): ... def init(self, hashval): ... self.hashval = hashval ... def hash(self): ... return hash(self.hashval) ... def eq(self, o): ... if not isinstance(o, hasher): ... raise TypeError("Cannot compare hashval to non hashval") ... return self.hashval == o.hashval

in python2.4:

dict.fromkeys([1, hasher(1)]) {1: None, <__main__.hasher object at 0xa7a5326c>: None}

in python2.5b2:

dict.fromkeys([1, hasher(1)]) Traceback (most recent call last): File "", line 1, in File "", line 8, in eq TypeError: Cannot compare hashval to non hashval

Yes this is made up code. But I'm not arguing for a feature; I'm arguing for backwards compatibility. Because we do not know where these legitimate uses are, we cannot evaluate their likelihood to exist nor the level of breakage they will cause. If we make this a warning for any exception, we can satisfy both imagined camps. Those in Armin's position can make that warning raise an exception while debugging, and those using it on purpose can squash it.

I understand the utility of being able to see this case happening. I'm not sure it's worth the warning. I'm positive it's not worth the backwards incompatibility of the raised exception.

Michael

Michael Urman http://www.tortall.net/mu/blog

More information about the Python-Dev mailing list