Issue1889394

>>> class Test(unicode):
...     pass
...
>>> a = Test('{1:1}')
>>> a == {1:1}
Traceback (innermost last):
  File "<console>", line 1, in ?
TypeError: unicode.__cmp__(x,y) requires y to be 'unicode', not a 'dict'

should return False.

i fixed this with the following patch: but i think it may be more of a work around than a fix.

Index: src/org/python/core/PyObject.java
===================================================================
--- src/org/python/core/PyObject.java   (revision 4112)
+++ src/org/python/core/PyObject.java   (working copy)
@@ -1253,7 +1253,7 @@
                 return res;
             return _cmpeq_unsafe(o) == 0 ? Py.True : Py.False;
         } catch (PyException e) {
-            if (Py.matchException(e, Py.AttributeError)) {
+            if (Py.matchException(e, Py.AttributeError) || Py.matchException(e, Py.TypeError)) {
                 return Py.False;
             }
             throw e;

Just realised that this seems to solve the problems with Py*Derived classes failing on == with other classes, but i'm not sure if this is hacky or not. I can't think of an example where classAobj == classBobj could ever be True except for when __eq__ is defined in the function, in which case, this fix doesn't affect that result.

After a bit more playing

with my patch:

>>> class A(unicode): pass
... 
>>> class B(unicode): pass
... 
>>> A() == B()
False

however, CPython returns True for this case.

After playing around for a bit, simply removing the toString() function from PyUnicodeDerived solves this problem.

There is also a problem with !=
here is an additional patch to fix it

--- a/jython/src/org/python/core/PyObject.java
+++ b/jython/src/org/python/core/PyObject.java
@@ -1264,6 +1264,11 @@ public class PyObject implements Serializable {
             if (res != null)
                 return res;
             return _cmpeq_unsafe(o) != 0 ? Py.True : Py.False;
+       } catch (PyException e) {
+            if (Py.matchException(e, Py.TypeError)) {
+                return Py.False;
+            }
+            throw e;
         } finally {
             delete_token(ts, token);
             ts.compareStateNesting--;

2.2 handles this correctly -- it looks like a TypeError raised here is 
new -- the expose MethodType.CMP descriptor is throwing it.

'hi' == {} still works ok because _cmpeq_unsafe calls PyString __cmp__ 
directly (which returns -2) but a call to a derived's __cmp__ actually 
calls its exposed __cmp__, which is compiled to throw a TypeError when 
it gets back -2

We probably just want the exposed __cmp__ to not throw a TypeError here 
instead. Assigning over to Charlie because I think he might have changed 
it (the exposer is causing the TypeError)

If we want to behave exactly like CPython, __cmp__ should continue
throwing TypeError ({}.__cmp__('foo') does throws such exception there).

It seems that CPython does some trickery after calling __cmp__, but
doesn't apply it to every object, as shown on
>http://pylonshq.com/pasties/779>. And, if I understand correctly, the
current patch is going to swallow TypeError on every __cmp__ invocation,
unlike CPython.

Oh, sorry, the broken URL should be http://pylonshq.com/pasties/779

BTW, my comment apply to the dict.__cmp__ behavior. I didn't realized
that this issue was about unicode.__cmp__ behavior, although both may be
 related.

this seems to be fixed in 2.5a1+

Indeed. 

I've also added test cases for some of the snippets shown on this issue
on r5134. Thanks!