Author terry.reedy
Recipients georg.brandl, medwards, rhettinger, terry.reedy
Date 2009-06-21.01:29:50
SpamBayes Score 3.1225e-13
Marked as misclassified No
Message-id <1245547792.74.0.686749307577.issue4395@psf.upfronthosting.co.za>
In-reply-to
Content
The situation appears to be at least slightly different from what Guido
stated. In 3.x, all classes subclass object, which has .__ne__, so if
that stopped inferred != behavior, it would never happen.

>>> class A:
	def __eq__(s,p): return 1

>>> id(object.__ne__)
10703216
>>> id(A.__ne__)
10703216

No new A.__ne__ added.  But

>>> c,d=object(),object()
>>> c==d
False
>>> c!=d
True
>>> a,b = A(),A()
>>> a==b
1
>>> a!=b
False

So it seems that a!=b *is* evaluated as not a==b rather than as
a.__ne__(b). If so, my revised suggested replacement would be:

"There is one implied relationship among comparison operators: defining
__eq__ causes '!=' to be evaluated as 'not ==' (but not the other way).
 There is no similar relationship for the order comparisons."

I am a bit puzzled though. In
ttp://svn.python.org/view/python/branches/py3k/Python/ceval.c?revision=73066&view=markup
I traced compare_op to cmp_outcome to (in object.c) PyOjbect_RichCompare
to do_richcompare to class specific tp_richcompare and I do not see the
special casing of eq. However, I am newbie at codebase.
History
Date User Action Args
2009-06-21 01:29:53terry.reedysetrecipients: + terry.reedy, georg.brandl, rhettinger, medwards
2009-06-21 01:29:52terry.reedysetmessageid: <1245547792.74.0.686749307577.issue4395@psf.upfronthosting.co.za>
2009-06-21 01:29:51terry.reedylinkissue4395 messages
2009-06-21 01:29:50terry.reedycreate