Lists on JPython 1.1b3

[Barry A. Warsaw]

>>>>> "EJ" == Eric Jacobs writes:

    EJ> I'm just trying to get started with JPython, and I'm having a
    EJ> little bit of trouble with attributes of lists. (Please let me
    EJ> know if this is not the best group to post about JPython in.)

No, this isn't the best list for JPython questions.  Please use
jpython-interest at python.org.  You can subscribe to this list by
visiting the URL

    http://www.python.org/mailman/listinfo/jpython-interest

but you don't need to subscribe in order to ask a question.  I'll
answer here anyway...

    >> l = [3,2,1] l.sort()
    EJ> Traceback (innermost last): File "<console>", line 1, in ?
    EJ> java.lang.NoSuchMethodError: org/python/core/PySequence:
    EJ> method __findattr__(Lja
    EJ> va/lang/String;)Lorg/python/core/PyObject; not found
    EJ>         at org/python/core/PyList.__findattr__
    EJ>         at org/python/core/PyObject.__getattr__
    EJ>         :

My knee-jerk answer is to turn of your JIT and try again.  I've just
seen too many problems go away when the JITs are disabled, so if you
see something unexpected, always always always, disable the JIT and
try again.  JPython generates legal Java bytecode of course, but it
does it in a way that's not quite typical of the patterns emitted from
a Java source code compiler, and it seems that JITs often have
problems doing the right thing.  It's a shame too, because I see
pystone performance improve by 10x with JITs turned on -- in fact on
my machine (Sparc Ultra 2, Solaris 2.6), pystones with JPython on a
JIT'd JVM are (slightly) better than CPython 1.5.2.

Anyway, I suggest this also because I tested this simple example out
on stock JPython 1.1beta3 and on my current CVS snapshot and had no
problems.   However, I had no problems even with the JIT enabled, but
that could be due to differences in the Java platform.

Okay, so assuming you do turn off your JIT and you still have the
problems, the best thing to do is to try to grab the latest CVS tree
and re-test it, or submit a complete code sample and sufficient
platform information into the JPython bug database.

    EJ> Traceback (innermost last): File "<console>", line 1, in ?
    EJ> TypeError: sort(): expected 0-1 args; got 6 ^^^ Since PyList
    EJ> is a class, PyList.sort should be an unbound method and should
    EJ> be taking at least one argument. This seemed sort of
    EJ> suspicious. (PyList.sort() with no args crashed the same way
    EJ> as the PyList.sort(l) above.)

No, you really can't call methods on builtin objects this way.  When
you do it this way, you don't really get an unbound method in the same
sense you would if you accessed a method through a Python class.  What
happens in this case is that the argument lists aren't getting aligned
correctly, so you never end up with a valid `self'.  You have to get
the method through normal Python attribute lookup in order to get self
pointing to the proper object.

    EJ> I looked at the dictionary class and found I didn't have any
    EJ> trouble getting dictionaries to work.

The trick you use works well if you're getting the methods through the
Java reflection mechanism.  In stock 1.1beta3 PyDictionary was using
reflection, not the new mechanism.  PyLists used the new mechanism.
Since the non-reflection mechanism is about twice as fast as using
reflection, I have adopted it for many of the methods of most of the
other built-in types.  I'm not sure it's worth continuing to support
the call format you're using for the builtin objects.

    EJ> I also noted that the methods of the non-functional list class
    EJ> and the working dictionary class were considered different
    EJ> kinds of methods:

    >> PyList.sort
    >> <builtin method 'sort'>
    >> PyDictionary.keys
    >> <java function keys at 685>

    EJ> This seemed to be a bogus distinction; since JPython is an
    EJ> implementation of Python in Java, shouldn't all "built-in"
    EJ> functions of Python really be Java functions?

They are actually implemented different Java objects.  In the latter
case, Java reflection is the primary mechanism for method lookup.  In
the former case, it's more explicitly coded (and as mentioned above,
twice as fast -- so the difference seems worth it).
    
So in general, for the builtin objects you should use the Pythonic way
of doing the method lookups.

Hope that helps,
-Barry