Message2307

Logged In: YES 
user_id=61408

I have looked at this:

1. comparisons and coercion are rather messy, it is hard to
distinguish what is language semantics at the moment vs.
hysterical raisins because of rich vs __cmp__ comparisions,
things still relying on coercion or not, the fact that
__coerce__ is only supported for old-style classes or by
coerce() builtin which OTOH is going to be phased out. See
PEPs 207,208 and the part about coercions in the Lang Ref.
2. Related: if you have noticed for __add__ etc we have
moved coercion logic insided the PyObject subclasses and
PyInstance, this is the spirit of PEP208, _cmp is the
exception, one thing
is that 3wy-comparision in CPython eagerly tries coercion in
both
direction, this is different for the binary ops.
[sadly btw as someone noticed the logic used by __add__ vs.
__coerce__ex__ are out of sync for some of our types]

3. This has prodded me to look seriously at comparision.

Consider this attached script.

Under python 2.2 the output is the following:
log: ['C_coerce'] coerce((),C()): (<__main__.D instance at
0x0076C0A8>, <__main_
_.D instance at 0x0076C070>)
log: ['C_coerce', 'C_coerce'] cmp(C(),C()): 1
log: ['C_coerce', 'D_eq'] cmp(C(),D()): 0
log: ['C_coerce', 'D_eq'] cmp(D(),C()): 0
log: ['D_eq'] cmp(D(),D()): 0
log: ['C_coerce'] C()==C(): 0
log: ['D_eq'] C()==D(): 1
log: ['D_eq'] D()==C(): 1
log: ['D_eq'] D()==D(): 1

A) coercing is attempted eagerly, this is different from out
__class__ comparison logic
B) the first C_coerce  in the logs for the cmp are because
of these lines in do_cmp in CPython 2.2 object.c:
	if (v->ob_type == w->ob_type
	    && (f = v->ob_type->tp_compare) != NULL) {
		c = (*f)(v, w);
		if (c != 2 || !PyInstance_Check(v))
			return c;
	}
and  that instance_compare in classobject.c try coercion
eagerly.
....