Proposal for .py2, py3, etc. extensions. Was: A way to accommodate laguage changes

[James Logajan]

Chris Barker wrote:
> A lot of python code is not in *.py files, and not run with the import
> statement. It is in dhtml, or a database, or an embedded script, or.....
> and run with exec or eval or execfile, or...
> 
> For this reason, there needs to be a version identifier in the code for
> this scheme to work.

Neither scheme is 100% perfect. A programmer new to Python who accidently
forgets to include a version identifier statement will have her module
silently compiled using old syntax and semantics. If they are learning
Python on their own (and that is how many people learn it), it will
eventually cause them frustration and confusion. A missing "optional"
statement that makes a large difference in how one's module is interpreted
will defeat Guido's underlying principle: reducing the "surprise" and
"non-intuitive" aspects.

How about using several schemes, with the following precedence:

1) The module contains a "UsesVersion" statement to indicate the operative
version.
2) The python interpreter is started with a flag to indicate the version to
compile with.
3) The module name contains a suffix to indicate the operative version.

If none of these are true, then old syntax and semantics apply.

P.S. When feeding eval() a string, I'm pretty sure it only takes an
expression; not a series of statements. You can't imbed a version statement.
So if, as you claim, there is indeed a lot of people who have string
snippets buried in databases or elsewhere that are evaled on the fly, then I
think that a lot of conversion pain is inevitable.