Message89553
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. |
|
Date |
User |
Action |
Args |
2009-06-21 01:29:53 | terry.reedy | set | recipients:
+ terry.reedy, georg.brandl, rhettinger, medwards |
2009-06-21 01:29:52 | terry.reedy | set | messageid: <1245547792.74.0.686749307577.issue4395@psf.upfronthosting.co.za> |
2009-06-21 01:29:51 | terry.reedy | link | issue4395 messages |
2009-06-21 01:29:50 | terry.reedy | create | |
|