Message5040
I opened issue 1437 to discuss PyProxy's misguided, silent creation of empty methods for abstract Java methods that don't have
a Python method. I'm only going to try to address the proxy's no-op method being preferred to a Python implementation here.
You don't even need Java code to produce this:
from java.lang import Runnable
class PyRun(object):
def run(self):
print 'Running from', type(self)
class RunnableFirst(Runnable, PyRun):
pass
class PyRunFirst(PyRun, Runnable):
pass
RunnableFirst().run()
PyRunFirst().run()
prints Running from <class '__main__.PyRunFirst'> which is notably lacking input from RunnableFirst.
Your analysis that the proxy's method is being found first is correct. Java types use Python's mro, and since the proxy class
is the first base, its method is called first. A simple fix for that is to exclude methods on generated proxy classes from its
dict. That makes them invisible from Python while leaving them in place for any calling Java code. Unfortunately, since the
proxy has the java interface as its base class, Jython then finds the method on the interface and attempts to call that. We
can prevent that by not returning abstract methods from lookups on Java classes. The attached patch does all of that, and gets
the code to work as expected.
It requires some pretty big changes, including some extra code in lookup, probably the most heavily used codepath in Jython.
As such, I don't think this should go in this close to 2.5.1. After 2.5.1 is released and stable, I'll look at actually
committing this if I still feel good about it. |
|
Date |
User |
Action |
Args |
2009-08-16 09:46:02 | cgroves | set | messageid: <1250415962.94.0.182789269442.issue1432@psf.upfronthosting.co.za> |
2009-08-16 09:46:02 | cgroves | set | recipients:
+ cgroves, alex.gronholm |
2009-08-16 09:46:02 | cgroves | link | issue1432 messages |
2009-08-16 09:46:02 | cgroves | create | |
|