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