[Josiah Carlson]
> ...
> >>> str < tuple < unicode
> True
>
> And you can actually compare str and unicode, so, if you have a str that
> is greater than the unicode, you run into this issue.
Oh dear -- I didn't realize we still had holes like that:
>>> 'b' < () < u'a' < 'b'
True
We used to have a bunch of those with numeric types (like int < list <
long), and then hacked comparison to artificially lump all "the
numeric types" together (by pretending that their type names are the
empty string -- see default_3way_compare() in object.c:
/* different type: compare type names; numbers are smaller */
if (PyNumber_Check(v))
vname = "";
).
That ensures, e.g., that int < list and long < list, despite that
"int" < "list" < "long".
> With unicode becoming str in Py3k, we may not run into this issue much
> then, unless bytes are comparable to str, in which case we end up with
> the same problems.
If Guido thinks about it in time :-), I expect it's more likely that
P3K will never fall back to comparing by type name; that non-equality
comparisons that currently fall back to looking at the type name will
raise exceptions instead. That's already the case for the types most
recently added to Python, like
>>> {} < set()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: can only compare to a set
>>> import datetime
>>> {} < datetime.datetime.now()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: can't compare datetime.datetime to dict
>>> {} == set()
False
>>> {} == datetime.datetime.now()
False
_______________________________________________
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
