bytecode non-backcompatibility

[Mike Meyer]

Maurice LING <mauriceling at acm.org> writes:

> I find this part of the story a nuisance, C components in 3rd party
> modules... What are the C components compiled into? What are actually
> "so" files?

Shared object files. They're executable code that can be linked into a
program at runtime. Like DLL's on Windows.

> I am using Fink to maintain my Python installation and Fink maintains
> the 3rd party libraries in /sw/lib/python2.3/site-packages. Imagine
> the trouble if I do a "fink selfupdate" and "fink update-all" and
> finds that my Python is replaced by a newer version, say Python
> 2.4. Then all my 3rd party libraries in
> /sw/lib/python2.3/site-packages are un-usable... And I will have to
> re-download and re-install all the libraries again.

Yeah, it's pain. It would be nice if setup.py kept a list of installed
packages that you could extract before updating, so you would know
what needed to be updated.

Last time I updated, I used the systems package handler. I asked it
for the names of all the Python packages that were installed and saved
that to a file. Then I installed the new version of Python. Then I
edited the package list to turn it into a series of package update
commands, and ran that file.

> Now I understand that Python bytecodes are only dealing with pure
> python source codes. However, the same question lies, how can it (set
> of bytecodes) be made stable, like Java bytecodes, which are pretty
> stable? Perhaps a better question will be, what techniques Java VM
> designers use that enables Java class files (and JAR files) to be
> stable and usable across versions that is lacking in Python?

All you have to do is convince the developers to declare the set of
bytecodes fixed, and they'd be stable. I don't think that will be
easy, as it removes one of the methods used to improve the performance
of Python. Since rebuilding the bytecode files is trivial (just invoke
compileall.py in the library as a script), this isn't really a
problem. The only thing that breaks are modules that muck about inside
the bytecode. I don't know how much bytecode improvements have sped
things up, but I do know that if I ever used a module that mucked
around with byte codes, I wasn't aware of it - so this is a tradeoff
I'm more than happy to make.

    <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.