One difference between Java and Python is this: Java bytecodes are, as I understand it, part of the Java language definition. CPython bytecodes are intentionally not part of the language at all. Except maybe fore PyPy, other implementations do not use them. Jython translates Python source to Java bytecodes. Pyrex translates augmented Python source to C, to be compiled to native machine code. Ironman translates, I presume, to .NET common language. PyParrot (don't know if it has an official name) translates to Parrot bytecodes. Viper translated to OCamel.
If you want an implementation with frozen bytecodes, you are free to make one ;-)
Terry J. Reedy
So there are currently 7 implementations or variations of the Python language and you are suggesting I make another one? If I am to do that, I will use CPython 2.4.1 and call it a implementation that maintains the current set of bytecodes (newer versions can have more bytecodes and deprecated bytecodes are still left there for backward compatibility) and C API interface. Till now I still do not know what is so exceedingly prohibitive to do that? Why should I create such a direct fork? Personally I do not have the resources to maintain this fork.
The Pacman (binary executable) that I played on a 286 a decade ago still works well on my brother's pentium III system, so from the point of a user, it is backward compatible. The same can't be said for .pyc files or .so files (I may be wrong with .so files here).
What I do have resources (time and energy) for is to work with the maintainers of PyPI to implement the package maintenance system I've described......
maurice -- http://mail.python.org/mailman/listinfo/python-list
