Here's how I set up my computer, for multiple versions.  Now to change
the "default", I just use the assoc command to change the association
for .py to one of the three listed ftypes.  Simple and quick.

c:\>ftype Python25.File
ftype Python25.File
Python25.File="C:\Python25\python.exe" "%1" %*

c:\>ftype Python26.File
ftype Python26.File
Python26.File="C:\Python26\python.exe" "%1" %*

c:\>ftype Python30.File
ftype Python30.File
Python30.File="C:\Python30\python.exe" "%1" %*

c:\>assoc .py
assoc .py
.py=Python25.File


It would be nice if the ftypes were version specific as created by the
installer; IIRC, I created the above three from the ftype Python.File as
I installed each version. 

The Python.File could still be created by default, and could still
reflect the last temporally installed version of Python... but by
documenting the version specific ftypes, the user could still switch
among versions.

I suppose there is a question of if the version should contain two or
three parts, i.e. Python253.File; and if the version should be separated
such as Python2.5.3.File; the above worked for me for the moment, but
some thought might reveal a more useful technique.

It might even be appropriate for a Python version to create 3 ftypes,
such that version N.M.O creates ftypes named PythonN.File,
PythonN.M.File, and PythonN.M.O.File.  All but the most specific one
would be subject to change when additional versions are installed.  If M
or O are zero, they should probably still be specified (as zero) in a
scheme like this, so that there would be a solid way of referring to all
the specific versions.

An extension to this idea:  Support parsing #! lines in Windows and 
select the version of Python used.  python.exe could examine:

#!/usr/bin/python30

pattern match "python##", look in the registry to see if that version 
of python is installed, and launch that python.exe instead.

Since Python hasn't done that until now, it won't help much with the
transition from 2to3.  The earliest versions that could add that would
be 3.1 and 2.7, it would seem, as it is a new fetaure.  Perhaps it would
be worth doing, in planning for Python 4...


Perl has done that for many versions.  The idea is useful for running
scripts that were designed and tested with a given version of Perl, on
that same version, to avoid the need to retest working, production,
code. Even when compatibility is supposed to be retained, and every
effort is made to do so in a maintenance release, sometimes little
things sneak in, that no one ever thought to test, and didn't to have
broken... so continuing to use the version with which a production
script was last extensively tested with, is "extra safe".

The technique you suggest isn't very good for testing a particular
script with various versions of python because you'd have to edit the
script to select the version.  It is good for being "extra safe" and
ensuring that a script continues to run with a particular version of the
interpreter.

I see this issue addressing the ability, in a testing environment, to
swap what version of implicit python is invoked for scripts invoked from
either the command line or from batch files, without the need to edit
the script or the batch file.  From the command line, it is relatively
easy just to invoke the right python via "c:\pythonNN\python script",
although that gets old if you are testing a large number of scripts.  So
I see it as primarily a convenience item for a testing environment.

I see it as primarily useful in this transition period between 2.x and 
3.0, since py3 scripts aren't backward compatible and I see both being 
installed for the few years.  It could be a front-end launcher 
suitable for "ftype Python.File" that inspects the script for #! and 
checks the registry for installed python versions.  That would make it 
work with older versions as well.  Probably better suited to 
discussion on c.l.p than here, but at least recorded as an idea in 
this feature request.

Ah yes, it could work as a front-end launcher, since # is a comment
character for Python anyway, so all Pythons would ignore such a line.

So that can be done completely independently of python itself, and
installed separately, and used by people that choose to.

In other words, feel free to write the program, and release it for all
that find it useful.  The sooner the better, eh?

I have created a script that does essentially what Mark Tolonen
suggests.  When it is provided a script to run, it looks for a #! line
and if it exists, attempts to use that to determine which version of
python.exe to use.  It also has the ability to install itself as the
default command for running .py files in the Windows registry.

Feedback welcome.

Python 2.5, 2.6, 3.0, etc. are not fully compatible programming languages. And we cannot expect that there will ever be the one and only ultimate version of Python (hopefully). Many of us need to have more than one of them installed simultaneously. Upon opening a Python file, the right version needs to be started. For those of us who use IDLE, we wish the right version to be started with “Edit with IDLE”. 

Therefore, we need a clean – pythonic – solution to this problem.

I am probably not qualified to determine the best such solution. My main concern is that the community takes the issue seriously.

Nevertheless, it seems to me that different file name extensions (.py25, .py26, .py30) would be a good candidate to solve the issue. On Windows, I set up the appropriate file type associations. It worked quite well, except that IDLE doesn't seem to recognize files with extensions other than .py.

Right now this would suit me down to the ground, as I'm running four maintenance versions, 2.6/7 and 3.1/2 in parallel.  But as this is a feature request it will not happen until 3.2 at the earliest.

Hum, I think I spoke too soon.  @Brian: @Tim: what do you think about this?

msg77014 could bring startup time down significantly so I'm -1 on that.

Overall I've never found difficulty in running scripts with the right version so I don't have a strong enough opinion on any of it. I think it's probably something which should be baked in python-ideas for a while to get a wider audience to think about it.

Effectively made redundant by PEP 397, implemented in 3.3