[Python-Dev] binary trees.

[Tim Peters]

[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