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:

class Something
public void someMethod(PyFunction f)
someMethod( turnPyFunctionsIntoMyOneMethodInterface(f) )
public void someMethod(IMyOneMethodInterface f)

Postr6952 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 java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuilder.append(StringBuilder.java:115)
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).