PEP 238 (revised)

[Chris Barker]

Guido van Rossum wrote:
> 
> Here's a completely revised version of PEP 238. 

Very nice. Let's hope this calms the waters some...

>     - Use a directive (or some other way) to specify the Python
>       version for which a specific piece of code was developed.  This
>       requires future Python interpreters to be able to emulate
>       *exactly* every previous version of Python, and moreover to do
>       so for multiple versions in the same interpreter.  This is way
>       too much work.  A much simpler solution is to keep multiple
>       interpreters installed.

I think this has been dismissed a little too quickly. I suppose I can't
comment on what "way too much work" is, as I really don't know how much
work it will be, and I'm unlikely to be doing any of it. I do think that
it is a lot of work for system administrators to keep all the old
interpreters around (particularly on new systems, it could be a fair bit
of work to get a working copy of Python 2.1 on RedHat 13.2 a few years
from now!) It seems to me that the worst case is that we end up with a
somewhat bloated interpreter that is essentially two (or three, or four)
completely separate interpreters that happen to be bundled together.
Given how cheap memory and disk space is these days, the bloat shouldn't
be a big deal, and you could always turn off the old code with a compile
option if you didn't need the backwards compatible interpreter.

I'm also not so sure about the emulate "exactly" issue. New features
that have been added but don't break old code could be along for the
ride, so you'd only have to emulate the code breaking ones, which have
been, and hopefully will be, few and far between. In this case, you are
planning on keeping the three opcodes, so the only difference would be
at the compiling state. In fact, it seems that the only difference
between the version 3.0 - epsilon version and 3.0 is that a bunch of
from __future__statements will be implied, so you already have a
mechanism in place to do it.

This kind of directive has the added benefit of immediately stopping
with an understandable exception when new code is run on old
interpreters.

Besides the sysadmin effort required to maintain multiple interpreters,
there this the issue of how the system knows which interpreter to use to
run a given piece of code. On *nix, you could change the #! line to
indicate version:

#!/usr/bin/env Python3.0.

On Windows, you are stuck with associating *.py files with python, so
you would have to add a new extension, perhaps *.py3. On the Mac, you
would have to add a new creator type, maybe "pyt3" (it's now "pyth").

Anyway, there is still time to give this some thought, I just think it
was dismissed pretty quickly, there was a little discussion on c.l.p,
but not much compared to all the other noise in the threads!

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------