Python 2.x breaks cmp() (was Re: A suspected bug)

Tim Peters tim.one at home.com
Sun Feb 18 12:23:50 EST 2001


[Andrew Dalke]
> >>> L=[1j, 2j]
> >>> L.sort()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: cannot compare complex numbers using <, <=, >, >=
> >>>

[Aahz Maruch]
> Is there any chance this can be treated as a bug and fixed for the
> release of 2.1?

Sure, but it's a small chance.  The reason all comparisons were
non-exceptional before isn't that Guido wanted that, but because the
implementation was such that it was literally impossible for a comparison to
raise an exception "that got noticed".  As soon as the implementation was
revamped to make raising visible exceptions from comparisons possible, Guido
was eager to drop comparisons outside of {==, !=} for complex numbers (as
Andrew said, there are several *possible* ways it could be done, but not a
one of them wouldn't surprise a majority of users).

What would change his mind is bug reports from people this actually hurts
(in practice).  So far no alpha user has filed a bug report against this.
Note that nobody is trying to hide that it changed, either:  there's a very
clear warning about this change of behavior in the alpha NEWS file.

> Alternatively, given that we're already breaking code with the change
> in the way complex numbers are handled, should cmp() now raise an
> exception *every* time the type/class differs?

Certainly not every time -- there's no practical or theoretical problem in
asking, e.g., whether 42 < 666L.  Forbidding that would be silly.  In
senseless cases, perhaps.  I suspect complex is being used to test the
waters before daring to dive in head first.

> I think the current situation is going to cause major problems trying to
> explain Python, particularly on the Unicode side.

Don't understand the last part.  I doubt anyone is comparing complex numbers
to Unicode strings today <wink>.  The only errors raised when mixing strings
and Unicode strings in comparisons occur in ambiguous cases where users
don't specify their intended encodings and so Python refuses to guess which
of the world's bazillion and one encodings they had in mind.  That's a
feature, albeit that it irritates people who think Python *should* read
their minds.

if-it-could-it-would-ly y'rs  - tim





More information about the Python-list mailing list