This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: fast swap of "default" Windows python versions
Type: enhancement Stage: resolved
Components: Installation Versions: Python 3.2
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: Andreas24, BreamoreBoy, brian.curtin, living180, matthieu.labbe, metolone, tim.golden, v+python
Priority: normal Keywords:

Created on 2008-12-02 08:51 by v+python, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit living180, 2009-08-23 12:25 Runs a Python script based on a #! line included in the script
Messages (11)
msg76731 - (view) Author: Glenn Linderman (v+python) * Date: 2008-12-02 08:51
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

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.
msg77014 - (view) Author: Mark Tolonen (metolone) Date: 2008-12-05 13:19
An extension to this idea:  Support parsing #! lines in Windows and 
select the version of Python used.  python.exe could examine:


pattern match "python##", look in the registry to see if that version 
of python is installed, and launch that python.exe instead.
msg77059 - (view) Author: Glenn Linderman (v+python) * Date: 2008-12-05 19:28
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

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.
msg77071 - (view) Author: Mark Tolonen (metolone) Date: 2008-12-05 21:19
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.
msg77099 - (view) Author: Glenn Linderman (v+python) * Date: 2008-12-06 04:15
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?
msg91887 - (view) Author: Daniel Harding (living180) * Date: 2009-08-23 12:25
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.
msg104735 - (view) Author: Andreas Lemke (Andreas24) Date: 2010-05-01 18:05
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.
msg111330 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-23 14:21
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.
msg111464 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-24 12:00
Hum, I think I spoke too soon.  @Brian: @Tim: what do you think about this?
msg111478 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-07-24 13:37
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.
msg164359 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-06-29 22:06
Effectively made redundant by PEP 397, implemented in 3.3
Date User Action Args
2022-04-11 14:56:41adminsetgithub: 48735
2012-06-29 22:06:21tim.goldensetstatus: open -> closed
resolution: wont fix
messages: + msg164359

stage: resolved
2010-07-24 13:37:49brian.curtinsetmessages: + msg111478
2010-07-24 12:00:34BreamoreBoysetnosy: + tim.golden, brian.curtin
messages: + msg111464
2010-07-23 14:21:24BreamoreBoysetnosy: + BreamoreBoy

messages: + msg111330
versions: + Python 3.2, - Python 2.6, Python 2.5, Python 3.0
2010-05-01 18:05:03Andreas24setnosy: + Andreas24

messages: + msg104735
versions: + Python 2.5
2009-09-08 14:52:19matthieu.labbesetnosy: + matthieu.labbe
2009-08-23 12:25:46living180setfiles: +

messages: + msg91887
2009-08-19 20:03:51living180setnosy: + living180
2008-12-06 04:15:33v+pythonsetmessages: + msg77099
2008-12-05 21:19:43metolonesetmessages: + msg77071
2008-12-05 19:28:39v+pythonsetmessages: + msg77059
2008-12-05 13:19:19metolonesetnosy: + metolone
messages: + msg77014
2008-12-02 08:51:58v+pythoncreate