Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Mark Dickinson added the comment: [Docs] "If both are numbers, they are converted to a common type." [Terry] "In any case, I think it is only true for built-in number types," It's not even true for built-in number types. When comparing an int with a float, it's definitely *not* the case that the int is converted to a float and the floats compared. And that's for good reason: the int -> float conversion is lossy for large integers, so if int <-> float comparisons just converted the int to a float before comparing, we'd have (for example):

...

...

10**16 == 1e16 == 10**16 + 1

leading to broken transitivity of equality, and strange dict and set behaviour. So int <-> float comparisons do a complicated dance under the hood to compare the exact numerical values of the two objects and produce the correct result. I'm not sure what the intent of the original sentence was, or how to reword it. The key point is simply that it *is* possible to compare an int with a float, and that the result is sensible, based on numeric values. ---------- nosy: +mark.dickinson _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Terry J. Reedy added the comment: In Python 3, where all classes inherit from object, the default rules are, by experiment, (which someone can verify from the code) simpler than you stated. 3. By default, == and /= compare identities. 4. By default, order comparisons raise TypeError. ob <= ob raises even though ob == ob because ob is ob. I am not sure of the method look-up rules for rich comparisons, but perhaps the following are true: 3) with == and !=, an object is equal to itself and different objects (a is not b) compare unequal, unless the class of the first define a specific __eq__ and __ne__; 4) with <, >, <=, and >=, comparison raises a TypeError, unless the class of the first object defines specific __lt__, __gt__, __le__, and __ge__, or the class of the second defines the reflected method (__ge__ reflects __lt__, etcetera); What is not clear to me is whether the reflected method is called if the first raises TypeError. The special method names doc (reference 3.3) says "A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments. ... There are no swapped-argument versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other’s reflection, __le__() and __ge__() are each other’s reflection, and __eq__() and __ne__() are their own reflection." Does 'not supported' mean 'raises TypeError', 'returns NotImplemented', or both? If the last, I don't really understand the reason for NotImplemented versus TypeError. That point should be clarified in 3.3 also. And 3.3 should be referenced in the comparisons section. I think point 5 should say a bit more: builtin numbers compare as expected, even when of different types; builtin sequences compare lexicographically. ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Ezio Melotti : ---------- type: -> enhancement _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Terry J. Reedy added the comment: After further thought: This section is about the syntax operators, not the special methods. The syntax operators never evaluate to NotImplemented as they (apparently) interpret its return from a special method the same as a raising of TypeError, and always raise TypeError when neither the op or its reflection is supported. So there should be no mention of NotImplemented here. Just a reference to 3.3. #15997 is related to my 'wonder' but not directly relevant to a patch for this. Please submit a draft patch when you have one. I determined that 'raise TypeError' and 'return NotImplemented' both result in the call of the reflected method, at least for a couple of cases. (And same seems true for arithmetic ops too.) class C(): def __ge__(self, other): # print("in C.__ge__", end='') return True def __add__(self, other): return 44 __radd__ = __add__ class O(): def __le__(self, other): # print ("in O.__le__") return NotImplemented def __add__(self, other): return NotImplemented c = C() o = O() ob = object() print(c >= o, o <= c, ob <= c) # True True True # print(ob <= ob) # raises TypeError print(c + o, o + c, ob + c) # 44 44 44 # print(ob + ob) # raises TypeError # print(ob >= o) # with O.__le__ print uncommented # in O.__le__ # so non-implemented reflected o <= ob *is* called # TypeError: unorderable types: object() >= O() ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Chris Jerdonek added the comment: Some minor comments: -The operators ``<``, ``>``, ``==``, ``>=``, ``<=``, and ``!=`` compare the +``<``, ``>``, ``==``, ``>=``, ``<=``, and ``!=`` compare the values of two I think it reads better to start a sentence (and in this case a paragraph) with a word rather than a symbol. -values of two objects. The objects need not have the same type. If both are +objects. The two objects don't necessarily have to be of the same type. With The replacement sentence seems wordier to me. +(:meth:`__ge__()` reflects :meth:`__lt__()`, etcetera). Builtin numbers compare +as expected, even when of different types. Builtin sequences compare "Built-in" is hyphenated in the docs. See, for example, here: http://docs.python.org/dev/library/functions.html ---------- nosy: +cjerdonek _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Terry J. Reedy added the comment: You are right, I did not look deep enough. I was fooled by the conversion of NotImplemented, returned from object.__le__, etc, to TypeError. Sorry for that noise. For comparison and arithmetic, the actual alternative to defining a function that returns NotImplemented seems to be to not define it at all. class C(): def __ge__(self, other): return True def __add__(self, other): return 44 __radd__ = __add__ class O(): pass # removed NotImplemented defs c = C() o = O() print(c >= o, o <= c) # True True print(c + o, o + c) # 44 44 (I looked at the codes for binary_op1 in abstract.c and do_richcompare in object.c and do not yet see any effective difference between not defined and a NotImplemented return.) I'll take a look at the patch later. ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Mike Hoy : ---------- hgrepos: -153 _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

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 http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: Uploaded issue12067-expressions_v3.diff for the 3.5 tip. Please review. ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: Uploaded issue12067-expressions_v4.diff to improve the unicode footnote 3, and to revert to using the term "lexicographical" for sequences (after learning that it applies there as well). Also, this version was produced using "hg diff" to make it properly reviewable. Please review. ---------- Added file: http://bugs.python.org/file35845/issue12067-expressions_v4.diff _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: Terry, I'd like to comment on your statement:

3. By default, == and /= compare identities. in msg148774.

What experiment lead you to that conclusion? Here is one that contradicts it (using cpython 3.4.1):

...

...

i1 = 42 f1 = 42.0 i1 == f1 True i1 is f1 False

Is it possible, that your experiment got influenced by the optimization that attempts to reuse existing objects of immutable types? Like in this:

...

...

i1 = 42 i2 = 40 + 2 i1 == i2 True i1 is i2 True

Andy ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: It seems I still need to practice creating patches ... uploading v6 which should create a review link. No other changes. Sorry for that. Andy ---------- Added file: http://bugs.python.org/file35851/issue12067-expressions-py34_v6.diff _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Terry J. Reedy added the comment: In py3, *everything* is an instance of class object. This makes like simple than in 2.x. The default comparison rules are set by the rich comparison methods of object. 'By experiment' meant by experiments with instances of object, which use those default methods, rather than by inspection of the relevant .c source code. Instances of subclasses taht do not override the defaults would act the same. Here is what seem to be the default code, from object.c, do_compare. It verifies what I said (v, w are pointers, which represent identity): /* If neither object implements it, provide a sensible default for == and !=, but raise an exception for ordering. */ switch (op) { case Py_EQ: res = (v == w) ? Py_True : Py_False; break; case Py_NE: res = (v != w) ? Py_True : Py_False; break; default: /* XXX Special-case None so it doesn't show as NoneType() */ PyErr_Format(PyExc_TypeError, "unorderable types: %.100s() %s %.100s()", v->ob_type->tp_name, opstrings[op], w->ob_type->tp_name); return NULL; } Py_INCREF(res); return res; Subclasses can and ofter do override the default methods. In particular, the number subclasses compare by value, across number types. ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Andy Maier : ---------- nosy: +benjamin.peterson, steven.daprano _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: Uploaded v8 of the patch for 3.4 and default. It reflects hopefully everything that was said in this issue thread, and on the python-dev mailing list (subject: == on object tests identity in 3.x), at least to the extent it was related to comparisons. Besides the doc changes it contained previously, it now also contains improvements for the test suite for comparisons (lib/test/test_compare.py). -> Please review both. Andy ---------- Added file: http://bugs.python.org/file35924/issue12067-expressions-py34_v8.diff _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Andy Maier : Added file: http://bugs.python.org/file35938/try_eq.py _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: Mark: Both are good points! Would you add the cases from your second comment under "symmetry"? ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: Uploaded v9 of the patch for 3.4 and default. It reflects Marc's comment, plus the result of the recent discussion on python-dev since v8 of th epatch, up to 2014-07-15 (subject: == on object tests identity in 3.x). -> Please review the patch. ---------- Added file: http://bugs.python.org/file35971/issue12067-expressions-py34_v9.diff _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Martin Panter added the comment: The point about “a != b” deferring to “not a.__eq__(b)” is not documented anywhere that I am aware of. In fact the opposite is currently documented at https://docs.python.org/release/3.4.0/reference/datamodel.html#richcmpfuncs, so maybe this needs to be fixed, one way or another. ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: Just wanted to say that i will continue working on this, working in the comments made so far... Andy ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: @Guido: Agree to all you said in your #msg226496. There is additional information about comparison in: - Tutorial (5.8. Comparing Sequences and Other Types), - Library Reference (5.3. Comparisons), - Language Reference (3.3.1. Basic customization) that needs to be reviewed in light of this patch. I'm just not sure I want to make this patch even larger as it is already, and tend to do that in a follow on issue and patch (unless directed otherwise). Andy ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: Here is the delta between v9 and v10 of the patch, if people want to see just that. ---------- Added file: http://bugs.python.org/file36897/issue12067-expressions-py34_delta-v9-v10.di... _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: I have addressed the comments by Jim Jewett, Martin Panter and of myself in a new version v11, which got posted. For the expression.rst doc file, this version of the patch has its diff sections in a logical order, so that the original text and the patched text are close by each other. Please review. ---------- Added file: http://bugs.python.org/file36920/issue12067-expressions-py34_v11.diff _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Andy Maier added the comment: I have posted v12 of the patch, which addresses all comments since v11. This Python 3.4 patch can be applied to the "default" (3.5 dev) branch as well. I will start working on a similar patch for Python 2.7 now. ---------- Added file: http://bugs.python.org/file36978/issue12067-expressions-py34_v12.diff _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Andy Maier : Added file: http://bugs.python.org/file38303/issue12067-expressions-py3.5_v14.diff _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Ethan Furman : ---------- nosy: -ethan.furman _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Berker Peksag added the comment: I think we can commit documentation and tests separately. I just did a quick review of the test changes and I will add some review comments later (sorry, lack of time :)). ---------- nosy: +berker.peksag _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Roundup Robot added the comment: New changeset 1fc049e5ec14 by Martin Panter in branch '3.4': Issue #12067: Rewrite Comparisons section in the language reference https://hg.python.org/cpython/rev/1fc049e5ec14 New changeset b6698c00265b by Martin Panter in branch '3.5': Issue #12067: Merge comparisons doc from 3.4 into 3.5 https://hg.python.org/cpython/rev/b6698c00265b New changeset 294b8a7957e9 by Martin Panter in branch 'default': Issue #12067: Merge comparisons doc from 3.5 https://hg.python.org/cpython/rev/294b8a7957e9 ---------- nosy: +python-dev _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Martin Panter : ---------- dependencies: +Wrong documentation (Language Ref) for unicode and str comparison _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Serhiy Storchaka : ---------- nosy: +r.david.murray _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Martin Panter : Added file: http://bugs.python.org/file46399/expressions-py3.7_v17.diff _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Cheryl Sabella added the comment: It appears all the patches for this issue have been applied. Is the only open item the changes to test_compare? ---------- nosy: +csabella _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________

Cheryl Sabella added the comment: I've created a PR for the changes to test_compare from v16 of the patch. ---------- _______________________________________ Python tracker http://bugs.python.org/issue12067 _______________________________________