On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> 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 PyExc_UnicodeWarning.
>
> 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 "<stdin>", line 1, in <module>
File "<stdin>", 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
