Re: bytecode non-backcompatibility

Maurice LING <mauriceling@xxxxxxx> 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@xxxxxxxxx> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
.

Relevant Pages

  • Re: Finding installed package files
    ... for making installation information more easily accessible? ... >> somewhere where more information about the key parts of the package ... >> As an example I installed the latest Python on Fedora 3. ... what one would expect is a form of help documentation much more integrated ...
    (alt.os.linux.redhat)
  • Install lxml package on Windows 7
    ... I need the lxml package to run a particular ... I found easy_install.exe in my Python 2.7 distribution. ... The usual installation pop-ups appear. ...
    (comp.lang.python)
  • Re: "zope3" dependency problem
    ... I am beginner user of etch distribution. ... Installation of "zope3" package causes installation ... If you look at the dependencies for package "python" ...
    (Debian-User)
  • Re: bytecode non-backcompatibility
    ... I don't think that will be easy, as it removes one of the methods used to improve the performance of Python. ... The current compilation scheme works well for scripting purposes but is less desirable in commercial settings. ... Unstable bytecodes makes updating to a newer version of Python very tedious and risk breaking old scripts, ... I remembered the time I was trying to install Eric 3, the dependencies makes me want to give up... ...
    (comp.lang.python)
  • Re: bytecode non-backcompatibility
    ... Python had gone from a purely scripting language to a general ... So you can't just ship java bytecodes to someone expecting they'll be ... > tedious and risk breaking old scripts, ... > the time I was trying to install Eric 3, ...
    (comp.lang.python)