Comparison of functions

Steven D'Aprano steve at REMOVETHIScyber.com.au
Sat Jul 30 09:34:06 EDT 2005


On Sat, 30 Jul 2005 08:13:26 -0400, Peter Hansen wrote:

> Beginners should not be comparing lambdas.
> 
> Neither should you. ;-)

Actually, yes I should, because I'm trying to make sense of the mess that
is Python's handling of comparisons. At least two difference senses of
comparisons is jammed into one, leading to such such warts as these:

>>> L = []
>>> L.sort()  # we can sort lists
>>> L.append(1+1j)
>>> L.sort()  # even if they include a complex number
>>> L.append(1)
>>> L.sort()  # but not any more
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, >, >=

Um, I didn't ask to compare complex numbers using comparison operators. I
asked to sort a list. And please don't tell me that that sorting is
implemented with comparison operators. That just means that the
implementation is confusing numeric ordering with sort order.

Then there is this:

>>> 1 > 0
True
>>> 1+0j == 1
True
>>> 1+0j == 1 > 0
True
>>> 1+0j > 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, >, >=

I applaud that Python has got rich comparisons for those who need them.
But by confusing the question "which comes first in a sorted list?" with
"which is larger?", you get all sorts of warts like being unable to sort
lists with some objects, while being able to make meaningless
comparisons like ''.join >= [].append.

I'm not sure what the solution to this ugly state of affairs is. I'm not
even sure if there is a solution. But I'm willing to make a good effort to
*look*, and even though you were joking, I don't appreciate being told
not to.



-- 
Steven.




More information about the Python-list mailing list