Python bytecode compatibility between interpreter versions

[Jon Perez]

Roger Binns wrote:

>>"The internal structure of a .pyc file depends on the implementation
>>details of the particular version of the Python interpreter that it was
>>compiled with"
>>
>>now when you phrase it that way, it makes sense...
> 
> No that is not what I meant.  What I meant is that the very existence
> of .pyc files is an implementation detail of one version of the Python
> interpretter.  Tomorrow it could use 3 different files, or none at all.
> They are pretty much an optional behind the scenes performance optimisation
> for CPython.  There is no requirement for them to exist.

Is it really the case that it isn't even recommended to distribute one's
application as .pyc files?

In commercial apps for which one might not want to distribute the source
for, it would be really nice if one can count on just requiring the end-user
to install a version of Python (but not extra extension modules anymore) and
then distribute the app as a bunch of .pyc's packaged in a .zip file and
use the PYTHONPATH method you showed.  Just remember to provide a set of
.pyc's for each version of Python you support.

> Java does something similar behind the scenes with HotSpot.
> It compiles things to native code, and keeps profiling information.
> They are not written out to disk and hence are not persistent
> between executions, but if they were the usage would be analogous
> to .pyc files.

In Java, profiling info may not be written out to disk, but the
bytecodes certainly are (they are what is in the class files).  Which
is roughly equivalent to what happens with .pyc files, correct?   .pyc
files don't contain profiling info, nor was I ever aware that the Python
VM even does run-time behaviour profiling... (Pysco may, though)

 > If you write your own Python interpretter/compiler, it will be
 > considered compliant if it implements the language correctly.
 > There is *nothing* about bytecodes, or bytecode compatibility.
 > For example if you wanted to write your own that ran on top of
 > Java, you would probably just directly generate class files.
 > If you wrote one that ran on a Palm device you would do something
 > else.  It is up to your implementation what it does.  The
 > only requirement would be working with Python *source* files.

Okay, I get it.  "Nothing in the spec specifies that .pyc files
have to exist". Further, "even the existence of a VM representation
is not part of the Python spec".

In practice though, there is really just one implementation of Python
(with the standard libraries... excluding Jython) which works using the
same bytecode mechanism on _all_ platforms, so as far as I can tell,
it would be quite feasible to distribute applications in .pyc form.