This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author andymaier
Recipients andymaier, chris.jerdonek, cvrebert, docs@python, ezio.melotti, mark.dickinson, mikehoy, rhettinger, terry.reedy
Date 2014-07-03.18:19:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Hi, I'd like to revive this issue.

IMHO, the changes in issue12067-expressions_v2.diff go too far. I don't think that deleting the entire section about the details of comparing objects of the same type makes sense.

I agree with Terry's statement in msg170936 that the chapter is about the operators and not about the ways to customize them, so some of what the patch introduces in that area should not be introduced.

So far, that means that I'm pretty much against that patch entirely...

Having said that, I do believe that there are still issues:

1. both the 2.7 and 3.x sections about the comparison operators are sufficiently convoluted and could be organized better by grouping the various statements that are made, into categories like this:

- comparisons involving objects of user-defined types
- comparing objects of same built-in type
- comparing objects of differing built-in type

2. There are still some errors, ambiguities and omissions that need to be fixed. For example, in the 3.x version:

a) omission about treatment of NaN for numbers of different type (could in theory be implied from the statement "are converted to same type", but that statement is problematic as was pointed out in Mark's comment on this issue).

b) Amgiguous statement "Most numeric types [of same type] can be compared with one another.". I think what is true is that all built-in numeric types (including Fraction and Decimal) compare mathematically correct in 3.x, and that the only non-support is that complex numbers are not considered orderable and an attempt to use an ordering operator raises TypeError.

c) Ambiguous statement "When cross-type comparison is not supported, the comparison method returns NotImplemented.". If this is about the customization methods, it should not be here, but there. Here, it is relevant that a TypeError is raised when using the operator.

d) Terminology in "Bytes objects are compared lexicographically using the numeric values of their elements.": Chapter [4.8.1. Bytes] defines bytes objects as immutable sequences of single bytes (not elements).

e) Terminology in "Tuples and lists are compared lexicographically using comparison of corresponding elements.": lists and tuples contain "items" not "elements", and an item-wise comparison should not be called "lexicographically" because that makes sense only when the items are characters.

f) Ambiguity in "If not equal, the sequences are ordered the same as their first differing elements.": "Are ordered" could be interpreted (e.g. by non-native speakers) to mean that the sequence is changed to achieve that ordering, which is not the case of course.

g) Editorial: In the list item about sets and froze sets, the example set {2,3} is not in example font.

h) Omission: Range types are not covered.

i) Omission: The section "Comparison of objects of differing types..." is silent about which built-in types support comparison across types (except for numeric types where that is covered). I think that should be explicitly listed for those built-in types that are also listed explicitly in the section about comparing objects of same type.

I'll try to come up with a patch for 3.x, and once that is agreed, with one for 2.x.

Date User Action Args
2014-07-03 18:19:36andymaiersetrecipients: + andymaier, rhettinger, terry.reedy, mark.dickinson, ezio.melotti, cvrebert, chris.jerdonek, docs@python, mikehoy
2014-07-03 18:19:36andymaiersetmessageid: <>
2014-07-03 18:19:36andymaierlinkissue12067 messages
2014-07-03 18:19:35andymaiercreate