> 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.