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

[James Logajan]

Chris Barker wrote:
> 
> Erik Max Francis wrote:
> > Paul Boddie wrote:
> >
> > > "from __past__ import" anyone? ;-)
> >
> > This occurred to me as well, but it still doesn't address the problem of
> > backward compatibility.  With a from __past__ import construct or not,
> > legacy code will still break.  The problem is not fixing old code, it's
> > being unable to fix old code that is no longer accessible (either from
> > being passed around or by being instrumented at a client site).
> 
> Exactly. I think everyone would be a LOT happier if you could run old
> code on a new interpreter, without ANY CHANGES AT ALL.
> 
> I think my proposal will allow that, someone plese commment on it!!

Sure: your proposal isn't bad. That is, absent any "pragma" the interpreter
assumes "old" semantics. But it does require programmers doing new
development to add that line of text in all their modules. And it has the
nice effect of spitting out an error when run by a 1.5.2 interpreter. But it
can get tiresome always adding that. So perhaps one should put the indicator
in the module name itself:

In the interest of proposing a solution everyone can live with, may I
suggest adoption of new module name extensions? A module named "module.py2"
will not be picked up or understood by Python 1.x on any platforms that I am
aware of. These would be compiled to either ".pyc", ".py2c", or ".pc2",
depending on whether one can compile the new semantics into code old
interpreters can handle, and whether it is now okay to allow more than 3
letters in file extensions on all popular platforms and file systems. But
hopefully everyone gets the idea.

Anyone see any insurmountable flaws with this? (Just trying to help; I hate
to abandon Python without at least trying one diplomatic solution to at
least one serious objection.)