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 mark.dickinson
Recipients Stephan Hoyer, mark.dickinson
Date 2017-04-23.08:45:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1492937107.38.0.666157287777.issue30140@psf.upfronthosting.co.za>
In-reply-to
Content
This is probably worth bringing up on the python-dev or python-ideas mailing lists for greater visibility. I can't think of any plausible non-historical reason why it makes sense for comparisons to behave one way and arithmetic operators another. Altering this might be a PEP-level change, though.

The "Coercion rules" section[1] of the Python 2.7 docs is a bit more explicit about the intent:

"""
Exception to the previous item: if the left operand is an instance of a built-in type or a new-style class, and the right operand is an instance of a proper subclass of that type or class and overrides the base’s __rop__() method, the right operand’s __rop__() method is tried before the left operand’s __op__() method.
"""

so the check for an override was clearly intentional, rather than an implementation convenience or accident. (It's also clearly intentional in the source and comments.) The 3.x docs don't have the "and overrides" language; I haven't figured out why and when that language changed.


[1] https://docs.python.org/release/2.7.6/reference/datamodel.html#coercion-rules
History
Date User Action Args
2017-04-23 08:45:07mark.dickinsonsetrecipients: + mark.dickinson, Stephan Hoyer
2017-04-23 08:45:07mark.dickinsonsetmessageid: <1492937107.38.0.666157287777.issue30140@psf.upfronthosting.co.za>
2017-04-23 08:45:07mark.dickinsonlinkissue30140 messages
2017-04-23 08:45:07mark.dickinsoncreate