More damage to intuition (was RE: [Python-Dev] Comparison of recursive objects)

[Tim Peters]

[Guido, on again lumping numbers together]
> I think I can put this behavior back.  (I believe that before I
> reorganized the comparison code, it seemed really tricky to do this,
> but after refactoring the code, it's quite easy to do.)

I can believe that; and I believe the "bugs" in 2.0 ended up somewhere in or
around the bowels of the xxxHalfBinOp-like routines (which were really
tricky to my eyes -- the interactions among coercions and comparisons were
hard to keep straight).

> My only concern is that under the old schele, two different numeric
> extension types that somehow can't be compared will end up being
> *equal*.  To fix this, I propose that if the names compare equal, as a
> last resort we compare the type pointers -- this should be consistent
> too.

Agreed, and sounds fine!  Save Barry a little work, though:

> ! 	/* Same type name, or (more likely) incomparable numeric types */
> ! 	return (v->ob_type < w->ob_type) ? -1 : 1;

That's non-std C in a way Insure complains about elsewhere; change to

	return ((Py_uintptr_t)v->ob_type <
		  (Py_uintptr_t)w->ob_type) ? -1 : 1;

if-vendors-stuck-to-the-letter-of-the-c-std-python-wouldn't-
     compile-at-all<wink>-ly y'rs  - tim