Logged In: YES 
user_id=4771

Sorry, I did not read well enough what object.c was doing. 
I agree now that your patch should protect again all
crashes, and that the concern is whether it is too restrictive.

Before rich comparison, there was no obvious sane way to
directly compare objects of different types in C extension
types.  I remember having the problem back in Python 1.5.2;
at the time I solved the problem with an nb_coerce that
returned "fake" objects of a common type, and a tp_compare
that decoded these fake objects.  Now I see that it would
have been simpler to solve the problem by either:

1) writing a nb_coerce that doesn't do anything (but which
is implemented; otherwise tp_compare don't get called at all).
This is what would be broken by the present patch.

2) easier yet, just making sure that both types have the
same tp_compare slot.  We don't need nb_coerce at all in
this case.  The tp_compare would check for the type of both
arguments anyway.  The present patch wouldn't break that.

There is no other reasonable safe way that I can of to fix
the problem (1)...  But admitedly the whole issue is a bit
far-fetched.  So I'd suggest that the issue is deferred
until Python 2.4 is out, and then we put the patch into the
pre-2.5 CVS head.  It's a bit late in the 2.4 release
process to risk breaking potential C extension modules.

A note about the patch: in the first comment you say that v
and w have different types, but that's potentially wrong --
they could have the same type but no tp_compare slot.

The new single test introduced after PyNumber_CoerceEx()
might be too restrictive: it would be enough if v and w have
the same tp_compare slot after coercion.  Pushing things a
bit over the edge of sanity, we might ask "what if coercion
returns old-style instances, or something with
_PyObject_SlotCompare?".  So maybe we should try the whole
try_3way_compare again after coercion (without of course
trying to coerce more than once!).