PEP 238 (revised)

[Chris Barker]

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

Since I last commented on this section, there have been a few other
comments, and I have had a few more thoughts.

"Terry Reedy" <tjreedy at home.com> writes:
> The only way I can think of to 'globally' turn on new division on my
> own Windows computer is to rebind .py and .pyc to python.bat
> containing '...python.exe -Dnew'.

Yes, but what do you do if you don't want the behaviour global? Then you
are stuck. 


Guido van Rossum wrote:

> Well, I hope that making the change Python 3.0 does the right thing
> for you.  It shouldn't be hard to alert your customers that Python 2
> is required for your company's applications.  Like Perl 4 and Perl 5,
> Python 2 and Python 3 will probably live alongside for many years.

I realise that my fantasy of an interpreter that fully emulates all
previous versions is just that, a fantasy, but if, as you say, Python 2
and Python 3 are going to be living alongside each other, than we need
to have a way of marking a given module as one of the other. File
extension is one possibility, but certainly a limited one, something in
the code itself would be better. Even if there is no integrated
interpreter, "python" could be a small script that dispatches the file
to the appropriate interpreter, similarly to Terry Reedy's batch file
above. The sysadmin could decide how many old versions to keep around.

> Requiring a version specifier in all new code is very annoying.  The
> future statement is annyoing too, but at least it's a transitional
> measure.

I think it is "a little annoying" rather than "very", and I just think
explicit is better than implicit.
I suppose it could be optional. If you have confidence that your code
will be run the right interpreter, you could omit it (A command line
option like -IgnoreVersion (or -RequireVersion) could be added to
support this).

> I agree that if we really need to have a way to explicitly request
> past behavior, "from __past__ import ..." is a decent syntax.  I just
> noticed that PEP 236 (the __future__ PEP) mentions this as an
> possibility (although the author claims it is unlikely).

The problem with the from __past__ statement is that we will end up with
many different dialects of the language, all of which need to be
supported (if it's too much work to have old versions supported, why is
this OK?) and will need to be supported forever! At least updating your
versions is a one-way street. Yes, if you want some of the new features
you have to take them all, but I thikn that's better that to have each
new feature optional!

-Chris


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