On Thu, 09 Jun 2005 15:50:42 +1200,
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Rocco Moretti wrote:
>> The main problem is that Python is trying to stick at least three
>> different concepts onto the same set of operators: equivalence (are
>> these two objects the same?), ordering (in a sorted list, which comes
>> first?), and mathematical "size".
> A possible compromise would be to add a new special method,
> such as __equal__, for use by == and != when there is no
> __eq__ or __ne__. Then there would be three clearly separated
> levels of comparison: (1) __cmp__ for ordering, (2) __equal__
> for equivalence, (3) __eq__ etc. for unrestricted semantics.
>> This gives the wacky world where
>> "[(1,2), (3,4)].sort()" works, whereas "[1+2j, 3+4j].sort()" doesn't.
Python inherits that wackiness directly from (often wacky) world of
Mathematics.
IMO, the true wackiness is that
[ AssertionError, (vars, unicode), __name__, apply ].sort( )
"works," too. Python refusing to sort my list of complex numbers is a
Good Thing.
> To solve that, I would suggest a fourth category of "arbitrary
> ordering", but that's probably Py3k material.
Four separate classes of __comparison__ methods in a language that
doesn't (and can't and shouldn't) preclude or warn about rules regarding
which methods "conflict" with which other methods? I do not claim to be
an expert, but that doesn't seem very Pythonic to me.
AIUI, __cmp__ exists for backwards compatibility, and __eq__ and friends
are flexible enough to cover any possible comparison scheme.
Why make the rules, the documentation, and the implementation even more
"interesting" than they already are?
Regards,
Dan
--
Dan Sommers
<http://www.tombstonezero.net/dan/>
--
http://mail.python.org/mailman/listinfo/python-list
