Forum Archive

As it's pure Python I thought it would be interesting to try PyJVM in Pythonista. It's installed, the test suite runs fine as well as a simple HelloWorld Java class compiled and copied into the package.

bytecode.ArraysTest     OK
bytecode.CalcsTest  OK
langfeatures.Hashes     OK
langfeatures.InnerClazz     OK
langfeatures.ThreadsDaemons     OK
langfeatures.ThreadsSync    OK
langfeatures.ThreadsSync    OK
sorts.HeapSort  OK
io.FilePrint    OK

ALL TESTS ARE OK 

Nice. But what's the point?

Jython I can understand - at least on the (z/OS) mainframe.

I suppose it's just to have a JVM of sorts on iOS - which Apple don't supply us with.

PyJVM and Jython are sort of opposites of each other.

• PyJVM is the Java Virtual Machine running on top of Python.
• Jython is Python running on top of Java.

Historically the problem with Jython has been that it lagged far behind Python releases. It is currently an implementation of Python 2.5.3. However there is new funding and there is now an Release Candidate 3 release of Jython 2.7 which should bring things up to date. See the video of last week's Jython talk at http://www.jython.org for details.

@MartinPacker For a general response see why.md in the PyJVM package. I have a specific interest though because I worked on VM/ByteCode software that predated Java. Reps from Sun met with me while Java was in development.

Apologies as this isn't quite on-topic, but I thought I'd post a link of an experiment to get Pythonista to execute externally-compiled Python bytecode binaries (.pyc). (Anyone searching the forum under the topic of bytecode VMs are more likely to come across this thread than the one that post was attached to)

@pacco Thanks, that's interesting... I didn't know about papaya.

@pacco Papaya had some dependencies on peak.util, but once those were satisfied it runs fine in Pythonista to dump, assemble and disassemble pyc's.

@tony -- that's great to hear. Although it was only a few months back, I can't quite recall if I assembled the example using Papaya with Pythonista or on a completely different platform and then copied just the bytecode data over. The value of doing the latter would have reinforced (to me anyway) the proof that Pythonista was loading and executing pure bytecode data.

I will admit to wondering if something like this (the Python bytecode generation part) could produce a .pyc that was usable by Pythonista. I haven't had the time to give it a try. (Hey, Python friends -- sorry for bringing up something related to R*** -- but we all have to come from somewhere right? :-)

@pacco. Thanks, interesting again, I'll look into that. Another confirmation would be that source for the fib function came from Python assembler and therefore couldn't be what Pythonista was loading and executing. Compiled with Papaya on Pythonista there's no need to then patch the magic number which is good because as the link you gave says of pyc's "they are independent of platform, but very sensitive to Python versions"

Snippet of fib.pya

# Example: fibonacci generator.
    LOAD_CONST def fib(n)
        # if n is 0, return 0
        LOAD_FAST n
        LOAD_CONST 0
        COMPARE_OP ==
        JUMP_IF_FALSE_OR_POP not_zero
        LOAD_CONST 0
        RETURN_VALUE

        # else if n is 1, return 1
    not_zero:
    Etc...

@pacco I took a look at your link:

• the cross-compiler and decompyle both target Python 2.5
• for decompyle however there is an equivalent uncompyle2 for Python 2.7 that installs and runs fine in Pythonista for turning pyc's back into their original Python source code...

hello.pyc

# 2015.05.05 18:23:53
# Embedded file name: hello.py
import math
print 'hello'

def hello2():
    print 'hello', 2


def hello():
    print 'hello'
    hello2()


print math.exp(10)
hello()
# okay decompyling hello.pyc 
# decompiled 1 files: 1 okay, 0 failed, 0 verify failed
# 2015.05.05 18:23:54

@tony, that's awesome!

If I weren't in the middle of such a heavy work week, I'd definitely ask about the details. For now, I just have this link to pass along. (Caveat: I haven't actually tried it).

http://stackoverflow.com/questions/7664189/how-to-recompile-the-python-2-5-bytecode-to-2-7

On the Jython side of the questions above, Jython 2.7 Final was released a few days ago. http://fwierzbicki.blogspot.fi/2015/05/jython-270-final-released.html

Perhaps @MartinPacker can run it on the mainframe and tell us how fast Python runs on super serious hardware without a Global Interpreter Lock (GIL). http://en.wikipedia.org/wiki/Global_Interpreter_Lock

@pacco Yes, it occurred to me that you could decompyle the cross-compiler 2.5 output to Python source and recompile that to 2.7. That's essentially the approach that byteplay takes I think, though it's doing it to something like an intermediate assembler representation. Like the link says, of course, "because of api differences the module may raise exceptions when run on 2.7 but then you can always..." edit the source for that.

Someone called my name, @ccc. :-) Jython on 141 z13 processors, with SMT-2 and possibly SIMD (if Java 8 JVM) oh my! :-) Oh, and 10TB of memory can't hurt. :-)

Seriously, it's time I looked at Jython more closely, again.