homepage

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 docs@python, mark.dickinson
Date 2014年07月23日.21:03:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za>
In-reply-to
Content
As reported in a StackOverflow question [1]: the order in which the special comparison methods are called seems to be contradictory to the docs [2]. In the following snippet, __eq__ is called with reversed operands first:
>>> class A:
... def __eq__(self, other):
... print(type(self), type(other))
... return True
... 
>>> class B(A):
... pass
... 
>>> A() == B()
<class '__main__.B'> <class '__main__.A'>
True
However, the docs note that:
"""If the right operand’s type is a subclass of the left operand’s type and that subclass provides the reflected method for the operation, this method will be called before the left operand’s non-reflected method. This behavior allows subclasses to override their ancestors’ operations."""
... which suggests that this reversal should only happen when the subclass B *overrides* A's definition of __eq__ (and indeed that's the usual behaviour for arithmetic operations like __add__).
Looking more closely, that statement in the docs is in the 'numeric-types' section, so it's not clear that its rules should apply to the comparison operators. But either way, some doc clarification could be useful.
[1] http://stackoverflow.com/q/24919375/270986
[2] https://docs.python.org/3.5/reference/datamodel.html#emulating-numeric-types 
History
Date User Action Args
2014年07月23日 21:03:30mark.dickinsonsetrecipients: + mark.dickinson, docs@python
2014年07月23日 21:03:30mark.dickinsonsetmessageid: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za>
2014年07月23日 21:03:30mark.dickinsonlinkissue22052 messages
2014年07月23日 21:03:29mark.dickinsoncreate

AltStyle によって変換されたページ (->オリジナル) /