Andy Maier added the comment:
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.
Andy
----------
nosy: +andymaier
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue12067>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
