On Jan 5, 2008 10:40 PM, hashcollision <[EMAIL PROTECTED]> wrote: > David A. Wheeler has already written a draft PEP, which can be found here: > http://www.dwheeler.com/misc/pep-cmp.txt.
Thanks, I'd missed that. But alas, it's a bit short on the motivation for rich comparisons. For example it fails to notice that quite a few object types need to be comparable for equality but need not be orderable. Comparison for equality only is often much faster than a full three-way-compare, since there is likely some quick test that decides two instances cannot possibly be equal (e.g. lists of different lengths). It also misses the use case of overloading < and <= as set inclusion operators. But the biggest thing missing is precise semantics. Saying "exactly the same semantics as with Python 2.5" doesn't cut it (those semantics are incredibly hairy and sometimes surprising, and their implementation was a nightmare -- I've rarely been as relieved as when I was able to cut those out of the implementation). A PEP should specify exactly what happens when both __cmp__ and one or more of the __xx__ operators are defined on the same class; it should specify what it means to override one or the other in a subclass; and it should define Python and C APIs for invoking __cmp__ (and what it should do if __cmp__ isn't defined). I also notice that, because not-equal can often be decided more quickly than a full ordering, the argument (which I brought up myself!) that not having __cmp__ would slow down list comparisons may be wrong or at least weak. E.g., for the sake of argument, let's assume that __eq__ is just 10% faster than __cmp__, and __lt__ is as fast as __eq__. Then comparing two lists using __cmp__ on successive element pairs would be slower than using __eq__ plus one final __lt__ if the deciding element is beyond the 9th index. If __eq__ is twice as fast as __cmp__ and __lt__ is the same speed as __cmp__, using __cmp__ would be slower beyond the 2nd index. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
