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