Issue5479
Created on 2009-03-12 08:18 by mrts, last changed 2022-04-11 14:56 by admin. 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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
Date: 2010-04-05 19:48 | |
http://en.wikipedia.org/wiki/Total_order |
|||
| msg102403 - (view) | Author: Éric Araujo (eric.araujo) * ![]() |
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) * ![]() |
Date: 2010-08-08 01:19 | |
Applied in r79810 Thanks for the suggestion. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:56:46 | admin | set | github: 49729 |
| 2010-08-08 01:19:51 | rhettinger | set | status: open -> closed resolution: accepted messages: + msg113228 |
| 2010-04-05 20:48:52 | LambertDW | set | messages: + msg102412 |
| 2010-04-05 19:53:57 | eric.araujo | set | messages: + msg102403 |
| 2010-04-05 19:48:54 | rhettinger | set | messages: + msg102402 |
| 2010-04-05 19:48:38 | mark.dickinson | set | nosy:
+ mark.dickinson messages: + msg102401 |
| 2010-04-05 19:46:44 | eric.araujo | set | messages: + msg102400 |
| 2010-04-04 01:33:47 | rhettinger | set | messages:
+ msg102315 versions: - Python 3.1 |
| 2010-02-16 08:37:57 | flox | set | priority: normal nosy: + flox versions: + Python 3.2 |
| 2010-02-16 06:02:50 | eric.araujo | set | nosy:
+ eric.araujo |
| 2009-04-25 00:16:48 | rhettinger | set | assignee: georg.brandl -> rhettinger |
| 2009-03-14 08:44:14 | mrts | set | messages: + msg83574 |
| 2009-03-13 18:42:52 | loewis | set | messages: + msg83528 |
| 2009-03-13 08:34:09 | mrts | set | messages: + msg83510 |
| 2009-03-12 20:26:42 | loewis | set | messages: + msg83502 |
| 2009-03-12 20:10:37 | LambertDW | set | messages: + msg83501 |
| 2009-03-12 18:57:33 | loewis | set | nosy:
+ loewis messages: + msg83499 |
| 2009-03-12 08:37:18 | LambertDW | set | nosy:
+ LambertDW messages: + msg83491 |
| 2009-03-12 08:18:36 | mrts | create | |
