Steven D'Aprano wrote: > 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.
Sorting is implemented with comparison operators. How should it be otherwise? Would you prefer a __sort__ method to specify sort order? And how would you sort a list of complex numbers? > Then there is this: > >>>> 1 > 0 > True Okay. >>>> 1+0j == 1 > True Okay. >>>> 1+0j == 1 > 0 > True (1+0j == 1) yields True, which is comparable to 0. >>>> 1+0j > 0 > Traceback (most recent call last): > File "<stdin>", line 1, in ? > TypeError: cannot compare complex numbers using <, <=, >, >= But complex numbers are not greater or littler than others. You can't order them, not on a one-dimensional scale. > 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. That's a wart indeed, and intended to be removed for 3.0, if I'm informed correctly. Reinhold -- http://mail.python.org/mailman/listinfo/python-list