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).

best,

Marc.