Python bytecode compatibility between interpreter versions

[Josiah Carlson]

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

It is not about Python being "less flexible" than Java, Python is 
evolving.  It is also stated in the docs somewhere that bytecode is not 
guaranteed to be forwards or backwards compatible.


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

Yeah, they try not to do bytecode changes mid point releases.


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

Virtual machine, interpreter, call it what you want.  There is probably 
documentation somewhere, but the best idea (if you are interested) is to 
just take a dive into the source.  It is all browsable on sourceforge.


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

IMO you are better off packaging them with py2exe or an equivalent for 
your platform.  Then you can guarantee that your users are running 
python version x.y.z, and not x.y.a (minor releases are to fix 
relatively important bugs, which may effect the execution of your program).


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

Such a PRE would not be small, and trying to get compatible versions of 
all of those 3rd party modules, for every supported platform, would be a 
pain in the ass.


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

There already exist 3rd party Python distributions with various add-ons. 
  I don't know of any off the top of my head (because I have no need for 
them), but I have heard mention of them here.

  - Josiah