Issue1605

classification
Title: float preference over PyComplex as arg to __call__ breaks logic
Type: Severity: major
Components: Versions: 2.5.1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: zyasoft Nosy List: babelmania, pjenvey, tomw2, zyasoft
Priority: Keywords:

Created on 2010-05-06.07:59:36 by babelmania, last changed 2010-06-16.14:50:46 by zyasoft.

Messages
msg5760 (view) Author: Jorgo Bakker (babelmania) Date: 2010-05-06.07:59:35
Consider the following Java class:
------------
public class Bar {
    public PyObject __call__(float x) {
        return dump(x);
    }
    
    public PyObject __call__(double x) {
        return dump(x);
    }
    
    public PyObject __call__(PyComplex x) {
        return dump(x);
    }
    
    private PyObject dump(Object o) {
        System.out.println("called with "+o.getClass()+"="+o);
        return Py.None;
    }
}
------------

calling this demo class in Jython as follows:
$ foo=Bar();
$ foo(2.);
called with class java.lang.Double=2.0
$ foo(1+2j);
TypeError: can't convert complex to float; use e.g. abs(z)
------------

This worked in Jython 2.1 and it seems that Jython 2.5.1 is broken in this respect.
msg5796 (view) Author: Tom (tomw2) Date: 2010-06-03.14:21:14
I hope this is related to the problem I posted in April on the email list.  In summary:  We have a Java class with two instance methods that have one argument:

method (double x)
method (Foo a)

Class Foo is also a Java class and has a method:
double  __float__()  {....}

The problem is that when I do this in Jython:

 a = Foo(10)
 b = Bar()
 b.method(a)

Jython seems to fetch the __float()__ value from Foo and then uses the
"method(double x)" signature.  In my mind, it should use the
"method(Foo val)" signature and pass in the instance of Foo.  In the
actual case, this is what we need to happen (and what 2.1 did).
msg5805 (view) Author: Jim Baker (zyasoft) Date: 2010-06-15.00:19:42
Apparently this is impacted by "faux" float support in PyObject#__tojava__ (as of 2.5). Given that floats have higher matching priority in ReflectedArgs the call path ends up not selecting what these users consider to be better matches in overloaded methods.

Instead, the precedence should go to a nonconversion path, if available. Changing ReflectedArgs#match seems to be the place to select this.
msg5815 (view) Author: Jim Baker (zyasoft) Date: 2010-06-16.14:50:45
Fixed by r7066.

tomw2 should adopt a similar solution to what was done with PyComplex#__tojava__ - there doesn't seem to be a reasonable way to indicate a preference without a rewrite of our reflection support. Therefore, modifying or adding __tojava__ seems like the better solution:

    // Special case __tojava__ for bug 1605, since we broke it with our support for faux floats.

    @Override
    public Object __tojava__(Class<?> c) {
        if (c.isInstance(this)) {
            return this;
        }
        return Py.NoConversion;
    }
History
Date User Action Args
2010-06-16 14:50:46zyasoftsetstatus: open -> closed
resolution: fixed
messages: + msg5815
2010-06-16 05:48:51pjenveysetassignee: pjenvey -> zyasoft
2010-06-15 00:19:43zyasoftsetnosy: + zyasoft
messages: + msg5805
2010-06-03 14:21:15tomw2setnosy: + tomw2
messages: + msg5796
2010-05-06 16:26:03pjenveysetassignee: pjenvey
nosy: + pjenvey
2010-05-06 07:59:36babelmaniacreate