bytecode non-backcompatibility

Terry Reedy tjreedy at udel.edu
Tue Apr 26 19:06:42 EDT 2005


"Maurice LING" <mauriceling at acm.org> wrote in message 
news:d4md4t$gfm$1 at domitilla.aioe.org...
> So there are currently 7 implementations or variations of the Python 
> language and you are suggesting I make another one?

Perhaps you missed the winkie ;-)

> The Pacman (binary executable) that I played on a 286 a decade ago still 
> works well on my brother's pentium III system, so from the point of a 
> user, it is backward compatible.

How well does it work on a P4 WinXP system?  If it does, you're lucky.  I 
have games that will not run in spite of the compatibility settings being 
set.  And so I will keep a Win95 machine and a Win98 machine for as long as 
they run.

>The same can't be said for .pyc files

The same *can* be said for some decade-old .py files.  Certainly, most 
everything written for 2.0 onward still works.  The same will also be true 
for .pyc files as long as you run them with their corresponding binary and 
as long as the binary stills run.

However, .pyc files are private, temporary caches created by a CPython 
interpreter for its own use and tied to its current implementation 
technology.  They are not intended to be a public distribution form and 
indeed cannot be a means to run Python programs on other interpreters. 
Guido has stated that he want the freedom to change or even replace parts 
of the internal implementation as he sees fit. (2.5 will probably get a new 
compiler, with the difference mostly transparent to users.)

One of the principles of OOP is separation of interface from 
implementation.  User of a class should only use the public interface and 
not depend on private implementation.  One reason is so implementation can 
be changed even radically as long as interface is kept constant.  The 
Python language is interface.  CPython bytecodes are implementation.

> What I do have resources (time and energy) for is to work with the 
> maintainers of PyPI to implement the package maintenance system I've 
> described......

Good.  I agree that we need more along that line.

Terry J. Reedy






More information about the Python-list mailing list