[issue14050] Tutorial, list.sort() and items comparability
New submission from Sandro Tosi <sandro.tosi@gmail.com>: I'm providing patches for what reported at http://mail.python.org/pipermail/docs/2012-February/007481.html . I'm not sure on wording or even if we want them in the tutorial section, but I think it would be nice to have it documented nonetheless. ---------- assignee: docs@python components: Documentation files: list_sort-py27.diff keywords: patch messages: 153648 nosy: docs@python, sandro.tosi priority: normal severity: normal stage: patch review status: open title: Tutorial, list.sort() and items comparability versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file24557/list_sort-py27.diff _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Changes by Sandro Tosi <sandro.tosi@gmail.com>: Added file: http://bugs.python.org/file24558/list_sort-py32.diff _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Ezio Melotti <ezio.melotti@gmail.com> added the comment: We could just mention that a TypeError is raised if some of the elements can't be compared. (Note that sorting a list that contains some types that cannot be compared might still succeed in some corner cases, but there's no reason to mention this). ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Éric Araujo <merwok@netwok.org> added the comment: If I had read your patched version when I was a beginner, I don’t think it would have helped me much. (Sorry for not coming up with an alternative right now, it’s late/early here and I’m tired :) ---------- nosy: +eric.araujo, terry.reedy _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Tshepang Lekhonkhobe <tshepang@gmail.com> added the comment: An an aside, shouldn't that be "in-place" instead of "in place (http://en.wikipedia.org/wiki/In-place)? ---------- nosy: +tshepang _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Éric Araujo <merwok@netwok.org> added the comment: Nope, the expression would be hyphenated only when used as an adjective: - “This sorts the sequence in place” vs. ‑ “Performs an in-place rearrangement by birthdate” ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Andy Maier added the comment: Just out of curiosity: Why do the patches attached to this issue not have a "review" link? Also, both (2.7 and 3.2) patches do not line up with the current 2.7 and 3.x tip, both hunks get rejected. Comments on both patches: 1. It would be helpful if the text "Each item needs to define an ordering relationship." was followed by a statement about what happens when that is not the case (that is what Ezio also suggested), and where to look for details on how to define an ordering relationship. The problem with that is that there is no good place that is devoted to exactly that. The relatively best place for defining comparison I found so far is: https://docs.python.org/2.7/tutorial/datastructures.html#comparing-sequences... and its 3.x equivalent. 2. The example that raises the TypeError is not needed, IMHO. This puts too much focus on the case that does not work. If we mention in the description that a TypeError is raised, that should be sufficient. Andy ---------- nosy: +andymaier _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Ezio Melotti added the comment:
Why do the patches attached to this issue not have a "review" link?
because
both (2.7 and 3.2) patches do not line up with the current 2.7 and 3.x tip, both hunks get rejected.
The "review" link only appears if the patch applies cleanly on the "default" branch. Preparing a new patch against "default" should make the link appear. ---------- type: -> enhancement versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Andy Maier added the comment: Ah! I was somehow suspecting that. Thanks for clarifying! I'll prepare a patch. To correct my earlier message, the best place to link for comparisons is probably the Conparisons subchapter of the Expressions chapter in the reference. See also issue12067. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
R. David Murray added the comment: The review link will also appear if the patch is generated via hg diff with diff.git turned *off*. You will note that both existing patches use --git, which omits parent changeset information, so our system can't figure out what to apply them against in order to generate the review link. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Changes by Raymond Hettinger <raymond.hettinger@gmail.com>: ---------- assignee: docs@python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Andy Maier added the comment: Uploaded patch version py34_v2, which contains the following changes relative to 3.4: 1. The changes in the description of list.sort() from "default" in list.sort(), by adding this text: (the arguments can be used for sort customization, see :func:`sorted` for their explanation) 2. The proposed extension of the description of list.sort() from patch version py32. 3. A statement that TypeError is raised if the ordering relationship is not established. 4. A reference where to look in order to establish ordering relationship for user-defined classes. (referencing the Basic customization section of the Language Reference). 5. A reference where the ordering relationships for built-in types are described (referencing the Comparison chapter of the Language Reference). -> Please review. Andy ---------- Added file: http://bugs.python.org/file35854/issue14050-list_sort-py34_v2.diff _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Andy Maier added the comment: uploaded patch version py27_v2, which contains the same changes as py34_v2, relative to 2.7, except for this differences: 1. The change from "default" was already in 2.7. 2. The reference to defining ordering methods for user-defined classes includes a reference to object.__cmp__(), in addition. -> Please review Andy ---------- Added file: http://bugs.python.org/file35855/issue14050-list_sort-py27_v2.diff _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Andy Maier added the comment: Comments on v2 of both patches: 1. The paragraph "Each item needs to ..." describes the requirement in terms of "ordering relationships between items". It would be both simpler and less ambiguous to describe the requirement in terms of "type must be orderable". See the text added to sorted() as part of the patch for issue10289, for details. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
R. David Murray added the comment: Unless I'm misremembering, it is exactly __lt__ (or __gt__, if __lt__ returns NotImplemented) that sorting depends on. Since I'm sure there is code out there that depends on this fact, I wonder if it should be part of the language definition. Also, the comparison documentation (https://docs.python.org/3/reference/expressions.html#comparisons) speaks about "total ordering" as being the requirement, which has a specific mathematical meaning (which sets, for example, do not satisfy, even though they have a __lt__ method). Whether or not the distinction is worth explaining in the tutorial is a open question. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Martin Panter added the comment: The first paragraph in the patch already seems to have been applied, for Issue 21575. The Sorting How-to <https://docs.python.org/dev/howto/sorting.html#odd-and-ends> already guarantees that defining only __lt__() is sufficient for sorted() and list.sort(). And the list.sort() specification <https://docs.python.org/dev/library/stdtypes.html#list.sort> says “only < comparisons” are used, which implies that only __gt__() may also be sufficient. It might be good to change “ordering relationship” to “total ordering relationship”, but I think further explanation and other details are probably not worth adding to the tutorial. They could be clarified in the main documentation, but that is probably a separate issue. ---------- nosy: +vadmium _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________
Change by Raymond Hettinger <raymond.hettinger@gmail.com>: ---------- pull_requests: +15091 pull_request: https://github.com/python/cpython/pull/15381 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue14050> _______________________________________
Raymond Hettinger <raymond.hettinger@gmail.com> added the comment: New changeset 4109263a7edce11194e301138cf66fa2d07f7ce4 by Raymond Hettinger in branch 'master': bpo-14050: Note that not all data can be sorted (GH-15381) https://github.com/python/cpython/commit/4109263a7edce11194e301138cf66fa2d07... ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue14050> _______________________________________
Change by miss-islington <mariatta.wijaya+miss-islington@gmail.com>: ---------- pull_requests: +15103 pull_request: https://github.com/python/cpython/pull/15395 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue14050> _______________________________________
Raymond Hettinger <raymond.hettinger@gmail.com> added the comment: New changeset cb8de91dadf15925fb95069cb190398e1d485f56 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-14050: Note that not all data can be sorted (GH-15381) (GH-15395) https://github.com/python/cpython/commit/cb8de91dadf15925fb95069cb190398e1d4... ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue14050> _______________________________________
Change by Raymond Hettinger <raymond.hettinger@gmail.com>: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue14050> _______________________________________
participants (9)
-
Andy Maier
-
Ezio Melotti
-
Martin Panter
-
miss-islington
-
R. David Murray
-
Raymond Hettinger
-
Sandro Tosi
-
Tshepang Lekhonkhobe
-
Éric Araujo