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