bytecode non-backcompatibility
Maurice LING
mauriceling at acm.org
Tue Apr 26 04:16:17 EDT 2005
> 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.
>
Thanks Mike,
My arguments to the developers will be:
1. Python had gone from a purely scripting language to a general purpose
programming language.
2. The current compilation scheme (compiling to bytecode as and when it
is needed) works well for scripting purposes but is less desirable in
commercial settings. Less distribution happens when it is used purely
for scripting purposes, such as system maintenance or tuning.
3. Using Python in commercial settings will usually require distribution
of resulting software and it is may or may not be desirable to
distribute source codes as well. Unless the application is frozen,
distributing source code is a must.
4. One advantage that Java platform has is that it does not require the
release of source files and still promotes platform-independence.
5. Unstable bytecodes makes updating to a newer version of Python very
tedious and risk breaking old scripts, if they uses C modules.
6. Unstable bytecodes also makes research work into Python, such as,
just-in-time compilation and just-in-time specialization unfavourable as
they may only be applicable to a specific version of Python. There is
much less chance of getting a project grant than if the same project is
applied for Java (stable bytecodes).
What other point are there?
I may be chopped by saying this but by having a stable set of bytecodes,
we may lose a means of optimization. But we may gain more from filling
the need for commerical distribution of applications writing in Python
and ease of upgrading...
At current stage, every time a new version of Python is installed in my
server or system, I have to test and ensure the needed libraries are
there... which may be a horror in corporate settings. Couple that with
messy dependencies of the libraries to be installed. I remembered the
time I was trying to install Eric 3, the dependencies makes me want to
give up... I have to install Qt, then pyQt, then something else, then
Eric3. Imagine you need 10 of those libraries... which may happen... I
am not yet masochistic enough to take pleasures in this...
I also hope some python developers are reading this thread as well......
Call this a desperate plea from some of us......
Cheers
Maurice
More information about the Python-list
mailing list