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 -- http://mail.python.org/mailman/listinfo/python-list
