bytecode non-backcompatibility

[Maurice LING]

> 
> 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