I'm responsible for that one. If it caused problems for you I'd love to get your feedback. I just threw it in there because it was a simple feature to add, but I haven't heard anything from anyone about what they thought of it.
Well, in some senses I was the ideal client of this code; but I happened to have this:
public void someMethod(PyFunction f)
someMethod( turnPyFunctionsIntoMyOneMethodInterface(f) )
public void someMethod(IMyOneMethodInterface f)
Post r6952 I get the second method called directly. Trouble is, my "turnPyFunctionsIntoMyOneMethodInterface" does something "special" (something very specific to my code). Still not realizing what was going on I insert:
System.out.println("what is this:"+f+")
into the second method only to have it give a ClassCastException.
java.lang.ClassCastException: java.lang.ClassCastException: org.python.core.PySingleton cannot be cast to java.lang.String
at $Proxy31.toString(Unknown Source)
at ((that System.out.println))
The invocationhandler in PyFunction needs to handle the methods in Object as well.
I'm probably in a community of one here and I can get round this by renaming "someMethod" to something else. So none of this is a vote against your change. PyFunction -> One method interface is "unsurprising" enough that I quickly guessed what was happening.
Ultimately PyFunction shouldn't be asked to coerce in this case, since there exists a method that can be called that doesn't require __tojava__ at all. Better (but slower) we'd have something like the wonderful XXPyObjectAdaptor system in reverse — to allow coertions to be specified outside of PyFunction.java (and, my favorite, PyGenerator).