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

[James Logajan]

Note: I should have called this a proposal for a new source file suffix to
match the terminology used in the library reference manual. I'll use
"suffix", rather than "extension", henceforth.

Chris Barker wrote:
> In the long, run, I think relying on file extensions ios a bad idea.
> Among othetr things, Python code is not neccesarily stored in files at
> all (at least not when passed to the interpreter)

But, but, Python ALREADY relies on file name suffixes! The "import"
statement:

import <module>

does NOT cause the interpreter to scan through every file in every directory
in sys.path, examining the contents of each and use some magical mechanism
to determine which ones are Python and are the module <module>. It looks for
files named <module>.so (or whatever the extension suffix for the given
platform), <module>.pyc, <module>.pyo, and <module>.py. It generally
REQUIRES proper suffixes to do its job. If it finds a .pyc then I believe it
looks at the "magic string" in it to determine which version of python it
was compiled with. That would tell the interpreter what behavior to use for
the "/" operator (or any other language change) for that module.

Compiled byte code files theoretically shouldn't be a problem, since the
"magic string" should already differentiate versions (although I'm not sure
what, say, a 1.5.2 interpreter does when it encounters a "non-conformant"
magic string for a later release). I'm also not sure what unusual uses users
have made of the "compile" function in the py_compile module, but I would be
surprised if anyone was using it with unusual file extensions. (Much less
breakage is likely here than that which would be caused by a change to "/"
semantics.) Actually, even there one could use the rule that if the file
doesn't end in .py2, (or whatever) then assume the source was written under
older versions. (However, a 1.5.2, say, might be accidentally be fed a .py2
this way; the proposal isn't 100% perfect. Just 98.7%.) As far as I can see,
there shouldn't be any obstacles getting the "imp" module and the "import"
statement to deal with a mix of .py and .py2 files. This proposal basically
adds an alternate suffix for source files.

To summarize, a new source code suffix has these properties:

1) Both humans and interpreters may know immediately by inspection of the
source file name what version of syntax and semantics to apply to the source
code.

2) Does not require old code to be rewritten in any way.

3) Does not require new code to have any special versioning statement
embedded in it.

4) Beginners can be instructed to use only the latest version suffix for
their source files until they have reached a high enough level of competence
and familiarity before trying to comprehend older code.

5) Provides the language designer(s) more latitude in designing in otherwise
code-breaking changes while still protecting the time invested in legacy
code.

6) Forces the language designer(s) to collect many changes to the language
in fewer quantum leaps. (That is, if one is limited to .py0, .py1, .py2, ...
.py9, then greater care will be taken in not "using up" the rather small
number of version numbers so quickly. I consider this a useful property.)

That is it; I can think of some minor objections or esthetic complaints, but
can't see any show stoppers unless I basically misunderstand some Python
internals.