Python bytecode compatibility between interpreter versions

Jon Perez jbperez808 at yahoo.com
Sat Mar 20 02:20:04 EST 2004


Peter Hansen wrote:

> Jon Perez wrote:
> 
>> Can one run a 1.5 .pyc file with the 2.x version
>> interpreters and vice versa?
>>
>> How about running a 2.x .pyc using a 2.y interpreter?
> 
> 
> What is the specific need you have?  There may be ways around
> your problem.
> 
> -Peter

I was just curious wrt deployment issues.  So I guess it is
fair to say that .pyc files are not as flexible as Java
class files which are at least forward compatible in most
cases (i.e. old class files will run on newer JVMs).

I'm sure a 2.N.x .pyc can run on a 2.N.y interpreter though,
right?  :-D

The answers also make me curious about how CPython's VM works.
I suppose that, unlike Java, it is constantly being reworked
in more extensive ways from one dot-version to another.  Would
that also explain why there is no detailed spec detailing how
CPython's VM works (since its design is not as nailed down as,
say, the JVM)?

As a programmer, I find installing (and uninstalling) Python
extensions to be about as easy as one can wish for.  However,
for end users, it would be great if we can someday have the
equivalent of a Java Runtime Environment with all the important
extensions already included.  Then Python developers can distribute
.pycs to end-users and expect them to work with few to no issues.

The things I would like to see in this hypothetical Python Runtime
Environment (PRE) would be Pygame, PyOpenGL, PyGtk (once it finally
matures on Aqua), and the other popular extensions they rely on (like
Numeric - although the current PyOpenGL is experimenting with
using numarray instead).

It may not necessarily have to be the current lightweight distro being
released by the offical Python maintainers, but a separate one
specifically geared for end users who mainly wish to use 3rd party apps
written in Python.  Due to Python's nature, such a PRE would also
automatically be an effective developer environment, nullifying the
need for an SDK edition.








More information about the Python-list mailing list