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.

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).

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 :)

An an aside, shouldn't that be "in-place" instead of "in place (http://en.wikipedia.org/wiki/In-place)?

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”

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-other-types 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

> 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.

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.

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.

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

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

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.

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.

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.

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/4109263a7edce11194e301138cf66fa2d07f7ce4

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/cb8de91dadf15925fb95069cb190398e1d485f56