classification
Title: Add an easy way to provide total ordering now that __cmp__ is deprecated/gone
Type: enhancement Stage:
Components: Documentation, Library (Lib) Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: LambertDW, eric.araujo, flox, georg.brandl, loewis, mark.dickinson, mrts, rhettinger
Priority: normal Keywords:

Created on 2009-03-12 08:18 by mrts, last changed 2010-08-08 01:19 by rhettinger. This issue is now closed.

Messages (15)
msg83490 - (view) Author: Mart Sõmermaa (mrts) Date: 2009-03-12 08:18
See http://mail.python.org/pipermail/python-dev/2009-March/087000.html
and http://code.activestate.com/recipes/576685/ .
msg83491 - (view) Author: David W. Lambert (LambertDW) Date: 2009-03-12 08:37
That's the best version I recall seeing at activestate.

Still, I'd deprecate and remove > and >= from mathematics.
msg83499 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-03-12 18:57
What is the purpose of this submission? What do you want to happen about
Python?
msg83501 - (view) Author: David W. Lambert (LambertDW) Date: 2009-03-12 20:10
(As I recall) in python-dev mailing list Ray claimed he could clean up a
cited active state recipe to address this issue.  He succeeded to the
extent I'm aware---he's the author of
http://code.activestate.com/recipes/576685/.

I haven't used the redundant >, >= comparisons operators in code since
1981.  The chances of simplifying python by removing them from the
language are None, but the mistake predates python by 10**n years, where
(3 <= n <= 7) or (7 >= n >= 3).
msg83502 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-03-12 20:26
Then why was this classified as a documentation issue? And why did Mart
Sömmermaa submit it, and not Raymond? AFAICT, Raymond said he would
propose something when it's ready (which I assume it currently isn't).
msg83510 - (view) Author: Mart Sõmermaa (mrts) Date: 2009-03-13 08:34
> Then why was this classified as a documentation issue?

As the documentation section of
http://docs.python.org/reference/datamodel.html#object.__lt__ needs to
be updated as well to mark the eventual solution as the recommended easy
way to provide total ordering.

> And why did Mart Sömmermaa submit it, and not Raymond? AFAICT, Raymond
said he would propose something when it's ready (which I assume it
currently isn't).

Raymond's recipe at http://code.activestate.com/recipes/576685/ looks
more or less complete, do you feel that his posting on the mailing list
does not count as proposal? I submitted the feature request instead of
him because I was the one who noticed the problem (as discussed on the
mailing list) and felt "responsible" to report it here.
msg83528 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-03-13 18:42
> As the documentation section of
> http://docs.python.org/reference/datamodel.html#object.__lt__ needs to
> be updated as well to mark the eventual solution as the recommended easy
> way to provide total ordering.

This is the 2.6 version. What about the 3.0 version in

http://docs.python.org/3.0/reference/datamodel.html#object.__lt__

needs to be updated?

> Raymond's recipe at http://code.activestate.com/recipes/576685/ looks
> more or less complete, do you feel that his posting on the mailing list
> does not count as proposal? I submitted the feature request instead of
> him because I was the one who noticed the problem (as discussed on the
> mailing list) and felt "responsible" to report it here.

I see. So it's a feature request.
msg83574 - (view) Author: Mart Sõmermaa (mrts) Date: 2009-03-14 08:44
> This is the 2.6 version. What about the 3.0 version in
> http://docs.python.org/3.0/reference/datamodel.html#object.__lt__
> needs to be updated?

When functools.total_ordering (whether it lands in functools is open)
lands that section should be amended in the lines of the following:

"There are no implied relationships among the comparison operators. The
truth of x==y does not imply that x!=y is false. Accordingly, when
defining __eq__(), one should also define __ne__() so that the operators
will behave as expected.

However, given a class defining one or more ordering methods,
`functools.total_ordering`_ class decorator can be used to fill in the
rest. Please see the documentation of `functools.total_ordering`_ for
further details."
msg102315 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-04-04 01:33
See r79730.

Leaving open until tests are written and all is forward ported to 3.2.
msg102400 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-04-05 19:46
Hello

Small documentation question: Does the expression “total ordering” have established usage in maths or computer science? Its meaning is not obvious to the non-maths person that I am.

Regards
msg102401 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-04-05 19:48
Yes, it's a standard mathematics term.

http://en.wikipedia.org/wiki/Total_order
msg102402 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-04-05 19:48
http://en.wikipedia.org/wiki/Total_order
msg102403 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-04-05 19:53
Thanks for the link. Please include it in the future doc if you judge it useful for a large number of users.

I’m still wondering if “total_ordering” is the best name for a decorator that fills the blanks to provide total ordering.

Regards
msg102412 - (view) Author: David W. Lambert (LambertDW) Date: 2010-04-05 20:48
http://en.wikipedia.org/wiki/Total_order

For pair of items from a set,  (that's the total)
if  a <= b  and  b <= c  then  a <= c  (part of the order)
if  a <= b  and  b <= a  then  a compares the same as b, a == b, (the
other part of the order)

On Mon, 2010-04-05 at 19:46 +0000, Éric Araujo wrote:
> Éric Araujo <merwok@netwok.org> added the comment:
> 
> Hello
> 
> Small documentation question: Does the expression “total ordering” have established usage in maths or computer science? Its meaning is not obvious to the non-maths person that I am.
> 
> Regards
> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue5479>
> _______________________________________
msg113228 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-08 01:19
Applied in r79810
Thanks for the suggestion.
History
Date User Action Args
2010-08-08 01:19:51rhettingersetstatus: open -> closed
resolution: accepted
messages: + msg113228
2010-04-05 20:48:52LambertDWsetmessages: + msg102412
2010-04-05 19:53:57eric.araujosetmessages: + msg102403
2010-04-05 19:48:54rhettingersetmessages: + msg102402
2010-04-05 19:48:38mark.dickinsonsetnosy: + mark.dickinson
messages: + msg102401
2010-04-05 19:46:44eric.araujosetmessages: + msg102400
2010-04-04 01:33:47rhettingersetmessages: + msg102315
versions: - Python 3.1
2010-02-16 08:37:57floxsetpriority: normal
nosy: + flox

versions: + Python 3.2
2010-02-16 06:02:50eric.araujosetnosy: + eric.araujo
2009-04-25 00:16:48rhettingersetassignee: georg.brandl -> rhettinger
2009-03-14 08:44:14mrtssetmessages: + msg83574
2009-03-13 18:42:52loewissetmessages: + msg83528
2009-03-13 08:34:09mrtssetmessages: + msg83510
2009-03-12 20:26:42loewissetmessages: + msg83502
2009-03-12 20:10:37LambertDWsetmessages: + msg83501
2009-03-12 18:57:33loewissetnosy: + loewis
messages: + msg83499
2009-03-12 08:37:18LambertDWsetnosy: + LambertDW
messages: + msg83491
2009-03-12 08:18:36mrtscreate