[ jython-Patches-859555 ] Rework _cmp_unsafe; test_compare passes

Patches item #859555, was opened at 2003-12-13 19:35
Message generated for change (Comment added) made by pedronis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312867&aid=859555&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Randy Brown (lycotic)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rework _cmp_unsafe; test_compare passes

Initial Comment:
Noting that the python code can call the top-level compare 
again after a coercion, I changed _cmp_unsafe to call _cmp 
again if the coercion did anything.

Also, python uses id() to order unordered classes.

Combined, these changes make test_compare.py pass.

----------------------------------------------------------------------

>Comment By: Samuele Pedroni (pedronis)
Date: 2004-01-26 21:06

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


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312867&aid=859555&group_id=12867


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn