Python bytecode compatibility between interpreter versions

[Roger Binns]

> Jon> Huh??  .pyc files are an "implementation detail of the Python
> Jon> interpreter"?  Care to expound further?  'Coz that sounds pretty
> Jon> nonsensical...
>
> "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.

Tomorrow I could write my own Python interpretter that generates
.tok files, .optim files and .silly files.  As long as it executes
Python *source* (ie .py files) then those are an implementation
detail.

In Java, the JVM only executes bytecode. In CPython it only
executes .py files.  Behind the scenes as an implementation
optimisation, the .py files are tokenised and transformed into
bytecode and used as internal representation.  As an implementation
specific performance measure, they are written out to .pyc
files which are loaded if not out of date in the future instead
of re-parsing the .py files.

You could delete every .pyc file on your system, and then mark
your disk as read-only and your Python programs will run fine.

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.

Roger