Backwards emulation rather than backwards compatibility?

[Tim Churches]

Antaeus Feldspar wrote:
> 
> I've seen both sides of the compatibility debate.  "You're breaking my
> scripts!" vs. "You're holding back the language!" and I can understand
> both sides.  While I do not think there is a perfect solution, I was
> struck the other day by a possible way to bridge the gap.
> 
> Could the python interpreter be equipped with a mode that would allow it
> to emulate past interpreters?  Thus, if someone needed access to a
> script that was designed for 1.5.2, they could pass a "--1.5.2" argument
> to the interpreter and have it run under 1.5.2's rules; more to the
> point, if a script's author wanted to be sure that their script could
> run on anything from 1.5.2 to 2.3, they could do it all with a single
> interpreter, rather than have to have a separate interpreter for
> checking each compatibility.
> 

I posted this some time ago:

> I sometimes use a statistics package called Stata. It has been around
> for well over a decade, with major upgrades to the core language released
> about every two years or so - hence there are three or four versions in
> common use. In order to allow users who are still running Stata V4
> to write routines which will behave correctly in Stata V7 (bit not vice
> versa), Stata has a "version" statement. If I am running Version 7, I can put
> something like
> "USE VERSION 4" (I don't recall the exact syntax) at the top of my
> programs and the program will be executed as if it were running in Stata V4.
> Hence, a user who still runs Stata V4 can put "USE VERSION 4" in every program and be
> sure these will work correctly when run in all subsequent versions of Stata.
> 
> This is the equivalent, I think, of having a "from __past__ import *"
> statement in Python, or more precisely, a "from __v1.5.2__ import *" statement.
> 
> Obviously it is impossible to retrospectively provide support for such a
> statement, but if there were a "from __v2.2.2__ import *" statement, one could put
> that at the beginning of every Python module one writes and be certain that the Bool
> type or any other newfangled feature would not trip up one's code at any time in the
> future, no matter how recent the version of Python used to execute it. Similarly a user of a
> recent version could verify that their code runs OK with older versions by using such a
> statement, which would of course disable all new language features and library modules, as well
> as making any new language behaviour revert to the old.
> 
> However, it may not be possible to avoid bloat in the Python core because successive
> versions of Python would need to support more and more old behaviour, but if this backwards support
> could be relegated to libraries, it shouldn't be too bad. Bloat in the Python core in
> order to support historical behaviour would be a lot less desirable, though.
> 
> And of course, such support for historical features and behaviour may also
> result in ever increasing intervals between releases of new versions of Python, as the
> developers struggle to accomodate ever more historical baggage.
> 
> Hence I don't think that any of the above is a good idea.
> 
> Tim C

But Martin v. Loewis points out:
> ...It is easy enough to install multiple
> versions of the interpreter, though.

Indeed it is (unlike many other languages which make having
multiple versions installed a nightmare), and these days the
extra disc space used by multiple installations is not a concern. So...

How about a Python meta-bytecode-compiler/interpreter which examines
Python source code and/or bytecode and automatically sends the code to 
the appropriate installed version of Python, resetting PYTHONPATH and
any other aspects of the environment appropriately?

Parsing the entire source and trying to infer which version of Python is
appropriate would probably be too slow (and a big job to write...),
so maybe an #ifdef-style directive could be put at the top of each 
Python script which triggers the appropriate behaviour, such as 

import __v1.5.2__ 

The module __v1.5.2__ would do nothing, but that line in the source 
would direct the meta-Python to use the correct version.

I'm not sure how such a meta-interpreter would deal with already
compiled
bytecode - is there a version stamp in the bytecode? 

If someone wants to write such a thing, I'd be happy to help test it...

Tim C