On 3/19/11 7:44 AM, Robert Miller wrote:
Dear Jason,
Jason-- You originally requested this. Why?
It looks like our discussion about why is up at
http://trac.sagemath.org/sage_trac/ticket/729
There is no discussion there-- you simply say it should be that way.
You cite an article, claiming that it states that rich comparison
operators are preferred. In fact, what the article states is that rich
comparison functions __eq__ etc. are called in preference of __cmp__,
which is not the same statement at all. That simply says that Python
looks for those first.
Unless anyone objects with good reason, I'm going to put all of this
back into a __cmp__ function. It makes no sense to have six functions
doing the same thing that one would do.
I read the first sentence
"http://docs.python.org/reference/datamodel.html#object.__ge__";, which is:
"These are the so-called “rich comparison” methods, and are called for
comparison operators in preference to __cmp__() below."
as saying the 6 functions are preferred ideologically to using __cmp__.
I see your way of reading it too.
In Python 3, it seems that __cmp__ is gone [1]. Additionally, it's not
listed at [2], and the only mention to easily making a total ordering
appears to be using functools.total_ordering(). We aren't dealing with
Python 3 yet, but it seems that not supporting those conventions now
will make things harder later.
Thanks,
Jason
[1]
http://docs.python.org/release/3.0.1/whatsnew/3.0.html#ordering-comparisons
[2] http://docs.python.org/py3k/reference/datamodel.html#basic-customization
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
