Python bytecode compatibility between interpreter versions

Jon Perez jbperez808 at yahoo.com
Sat Mar 20 09:39:31 EST 2004


Josiah Carlson wrote:

> It is not about Python being "less flexible" than Java, Python is 
> evolving.  

Note that I specifically mentioned .pyc files vs. java class files,
not Java the language/environment/platform vs. Python.

 > It is also stated in the docs somewhere that bytecode is not
> guaranteed to be forwards or backwards compatible.

Ah ok.

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

Right.  I am aware that freezing is the optimal way to distribute
apps written in Python today.  After trying out Java though, I have
to say I'm impressed with the way you can take a bunch of class
files archived in the exact same jarfile to *ANY* computer with a
JRE installed, type in java -jar jarfile and have it run _identically_.

Perhaps one day .pyc files can work in such a manner.

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

That it would not be small I will agree with you on, however I don't
believe version [in]compatibilities will become a PITA as it isn't so
even today.

The whole idea of a Python Runtime Environment came to me precisely
because I have tried out Pygame, PyOpenGL, PyGTK on both Win32 and
Linux and they work seamlessly and uniformly on both platforms (not sure
on OS X though).  Note that these are modules that tie intimately with
_different_ low-level APIs on each platform but they work so flawlessly
that it reminds of me of Java's WORA which has been a reality for a
long time now.  The main difference is that with Python, getting all
these different modules (for multimedia, 3d acceleration, GUI) installed
involves more steps (though quite easy).  Also, because these work
on top of C-based APIs, the performance is significantly superior to
Java's.

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

ActiveState's and Pythonware's are the two I am aware of.



More information about the Python-list mailing list