Meador Inge <mead...@gmail.com> added the comment: > I'm not sure that's a good idea: mightn't this change behaviour for > user-defined classes with a __coerce__ method? Maybe it would be > better to just special-case ints and longs at the start of > complex_richcompare, and then leave everything else more-or-less > intact?
I looked into this more and agree. I have attached a patch with the strategy that leaves the coercion intact. Although, even with removing the coercion from the complex rich compare a user-defined __coerce__ is still called somewhere up in object.c. It does not have the same behavior, though, e.g. __coerce__ is called, but the coerced args don't actually seem to be used in the comparison as they are in the explicit coerce in the complex object rich compare. Somewhat of topic, but the comparison rules in 2.7 seems to be pretty inconsistent anyway (due to different behavior between new and old style classes): motherbrain:trunk minge$ ./python.exe Python 2.7b2+ (trunk:81489M, May 29 2010, 09:44:06) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from itertools import product [35627 refs] >>> class T: ... def __init__(self, x): ... self.x = x ... def __coerce__(self, other): ... return (self.x, other) ... [35676 refs] >>> class U(T, object): ... def __init__(self, x): ... super(U, self).__init__(x) ... [35723 refs] >>> for tobj, value in product((T, U), (12, 12.0, complex(12.0))): ... print tobj, " -> ", tobj(value) == value ... __main__.T -> True __main__.T -> True __main__.T -> True <class '__main__.U'> -> True <class '__main__.U'> -> False <class '__main__.U'> -> True [35740 refs] >>> Given the complexities and subtleties of how comparison works in 2.7 I am a little hesitant to commit this change as well. ---------- Added file: http://bugs.python.org/file17493/issue-8748.py27.2.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8748> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
