Multiple Versions of Python on Windows XP

[Colin J. Williams]

Could anyone please point me to
documentation on the way the msi
installer handles multiple versions eg.
Python 2.5, 2.6 and 3.0?

What changes are made to the registry?

Is there some way to specify a default
version in such a way that it can be
changed as necessary?

PyScripter uses an option to select a
version eg.

C:\Program
Files\PyScripter\PyScripter.exe --python26

but I'm having some trouble with it when
I attempt edit a python file from the
Windows Explorer.

I would appreciate any information.

Colin W.

 

[Martin v. Löwis]

Could anyone please point me to documentation on the way the msi

installer handles multiple versions eg. Python 2.5, 2.6 and 3.0?

I don't think that is documented anywhere.

What changes are made to the registry?

For a complete list, see Tools/msi/msi.py in the source tree.

Is there some way to specify a default version in such a way that it can
be changed as necessary?

What do you mean by "default version"?

There is the version that is associated with the .py/.pyc extensions
at any point in time; you can change these by re-running the respective
installers from add-and-remove-programs. In a well-managed installation,
only one Python installation would have the "Register Extensions"
feature selected; to then change the default, one would unselect the
feature in one version, and reselect it in a different. If only the
default installation procedure was ever used, re-running the installer
in "Repair" mode (from ARP) will also restore the extension
associations.

PyScripter uses an option to select a version eg.

C:\Program Files\PyScripter\PyScripter.exe --python26

but I'm having some trouble with it when I attempt edit a python file
from the Windows Explorer.

It would be good to be more specific with such statements: what troubles
specifically? If I play dumb, I'd say "of course - windows explorer
doesn't support editing Python files; you need a text editor".

Regards,
Martin

 

[Glenn Linderman]

What do you mean by "default version"?

There is the version that is associated with the .py/.pyc extensions
at any point in time; you can change these by re-running the respective
installers from add-and-remove-programs. In a well-managed installation,
only one Python installation would have the "Register Extensions"
feature selected; to then change the default, one would unselect the
feature in one version, and reselect it in a different. If only the
default installation procedure was ever used, re-running the installer
in "Repair" mode (from ARP) will also restore the extension
associations.

That seems a lot more cumbersome than just using the command line to
change the ftype and assoc a bit. 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.

 

[Martin v. Löwis]

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.

That's a good idea; please submit a wish list item to bugs.python.org.
There may be issues (such as people relying on this being Python.File),
but I can't see any problems off-hand.

Regards,
Martin

 

[Glenn Linderman]

That's a good idea; please submit a wish list item to bugs.python.org.
There may be issues (such as people relying on this being Python.File),
but I can't see any problems off-hand.

Regards,
Martin

OK, Issue 4485 created. My first one, so let me know if I goofed. I
elaborated a bit from the original email, upon reflection. Seemed
useful, but also seemed complex by the time I got done.

I don't really have a clue what the uninstaller should do with these;
nor have I fiddled to know if it presently removes Python.File. I
suppose it should delete them, if and only if the ftype and assoc have
the same content as was created by the corresponding version installation.

 

[Martin v. Löwis]

OK, Issue 4485 created. My first one, so let me know if I goofed. I

elaborated a bit from the original email, upon reflection. Seemed
useful, but also seemed complex by the time I got done.

Looks about right to me.

I don't really have a clue what the uninstaller should do with these;
nor have I fiddled to know if it presently removes Python.File. I
suppose it should delete them, if and only if the ftype and assoc have
the same content as was created by the corresponding version installation.

The uninstaller will currently just remove it all. Conditional removal
of the associations will be tricky; I'll look into it.

I also wonder whether assoc only changes the settings for the current
user. In that case, uninstalling a Python version that was per-machine
would not affect the user's association, anyway.

Regards,
Martin

 

[Colin J. Williams]

I don't think that is documented anywhere.


For a complete list, see Tools/msi/msi.py in the source tree.

I have scanned the file:
http://svn.python.org/projects/python/branches/py3k/Tools/msi/msi.py

I don't find anything that addresses
this issue.

What do you mean by "default version"?

I am seeking some mechanism such that
any of Python 2.5, Python 2.6 or Python
2.6 can be chosen as the currently
active version.

There is the version that is associated with the .py/.pyc extensions
at any point in time; you can change these by re-running the respective
installers from add-and-remove-programs. In a well-managed installation,
only one Python installation would have the "Register Extensions"
feature selected; to then change the default, one would unselect the
feature in one version, and reselect it in a different. If only the
default installation procedure was ever used, re-running the installer
in "Repair" mode (from ARP) will also restore the extension
associations.

I was hoping that there is some simpler
way than the "Repair" procedure.

It would be good to be more specific with such statements: what troubles
specifically? If I play dumb, I'd say "of course - windows explorer
doesn't support editing Python files; you need a text editor".

Yes, I should have been clearer. The
PyScripter application locks up and must
be killed, using the Task Manager.

Many thanks for your response.

Best wishes,

Colin W.

 

[Martin v. Löwis]

What changes are made to the registry?

I have scanned the file:
http://svn.python.org/projects/python/branches/py3k/Tools/msi/msi.py

I don't find anything that addresses this issue.

Read the add_registry function. You may need to first understand
how the Registry table in an MSI file works.

I am seeking some mechanism such that any of Python 2.5, Python 2.6 or
Python 2.6 can be chosen as the currently active version.

If Glenn Lindermann's answer doesn't help, you need to explain:
what is a "currently active version"? How is one Python version
more active than any other?

I was hoping that there is some simpler way than the "Repair" procedure.

See Glenn Lindermann's answer.

Yes, I should have been clearer. The PyScripter application locks up
and must be killed, using the Task Manager.

I think you need to report that to the PyScripter authors as a bug.
I can't imagine how the "currently active version" can affect what
PyScripter does.

Regards,
Martin

 

[Colin J. Williams]

Read the add_registry function. You may need to first understand
how the Registry table in an MSI file works.


If Glenn Lindermann's answer doesn't help, you need to explain:
what is a "currently active version"? How is one Python version
more active than any other?


See Glenn Lindermann's answer.

I'll look at it
Using a right click, one can open any
..py file with say SciTe. Within SciTe,
one can Run the current file.

It would be good to have the appropriate
version (my use of "default") preselected.

I think you need to report that to the PyScripter authors as a bug.
I can't imagine how the "currently active version" can affect what
PyScripter does.

Yes, I'll do that.

I'll also follow up with Glenn
Lindermann's answer.

Many thanks,

Best wishes,

Colin W.

 

[Martin v. Löwis]

Using a right click, one can open any .py file with say SciTe. Within

SciTe, one can Run the current file.

It would be good to have the appropriate version (my use of "default")
preselected.

I don't know how SciTe choses the version of Python to run. In the
sense in why you use the word, there might just not be a "default"
version of Python on Windows. Somebody who knows SciTe better may
correct me.

Regards,
Martin

 

[Méta-MCI (MVP)]

Hi!

Multiple versions of Python is possible (example: Python standard +
Python by OOo).
But, multiple versions of Python+PyWin32 is not possible.

Suggestion: use VirtualBox or Virtual-PC.

@-salutations

 

[Jason Scheirer]

Could anyone please point me to
documentation on the way the msi
installer handles multiple versions eg.
Python 2.5, 2.6 and 3.0?

What changes are made to the registry?

Is there some way to specify a default
version in such a way that it can be
changed as necessary?

PyScripter uses an option to select a
version eg.

C:\Program
Files\PyScripter\PyScripter.exe --python26

but I'm having some trouble with it when
I attempt edit a python file from the
Windows Explorer.

I would appreciate any information.

Colin W.

Some more factoids that may be of use:

1. The last Python you install will take over all the file
associations, start menu stuff, etc.
2. You can enumerate over the Pythons you have installed in \
\HKEY_LOCAL_MACHINE\Software\Python\PythonCore\
3. If you silently install a Python PACKAGE made with distutils'
bdist_msi, it will by default install to the latest Python version it
finds (2.6 > 2.5 > 2.4 > 2.3)

 

[Colin J. Williams]

Read the add_registry function. You may need to first understand
how the Registry table in an MSI file works.


If Glenn Lindermann's answer doesn't help, you need to explain:
what is a "currently active version"? How is one Python version
more active than any other?


See Glenn Lindermann's answer.


I think you need to report that to the PyScripter authors as a bug.
I can't imagine how the "currently active version" can affect what
PyScripter does.

Regards,
Martin

Martin,

Many thanks for your responses. Yes,
Glen Lindermann's suggestion seems to
meet the need.

It's been a while since I've looked at
DOS and I didn't remember fType or assoc.

Michel Claveau suggests VirtualBox, this
seems a big hammer to kill
this particular fly.

It's interesting that each install sets
up a Python.File variable in the registry.

It's a pity that this can't be used to
achieve this more simply.

Best wishes,

Colin W.

 

[Glenn Linderman]

Martin,

Many thanks for your responses. Yes,
Glen Lindermann's suggestion seems to
meet the need.

It's been a while since I've looked at
DOS and I didn't remember fType or assoc.

The equivalent of those commands is available via Windows Explorer,
Tools / Folder Options, File Types, scroll-scroll-scroll your way to
..py, Click Advanced, fiddle, copy paste apply, and other twaddle. A
perfect example of why not everything should be done via GUI interfaces,
or at least why this is an extremely poor GUI interface.

GUI designers should count the command line keystrokes, and make sure
their interface is shorter, otherwise they are a failure.

Michel Claveau suggests VirtualBox, this
seems a big hammer to kill
this particular fly.

It's interesting that each install sets
up a Python.File variable in the registry.

It's a pity that this can't be used to achieve this more simply.

Martin seems willing to entertain the idea of future Windows installers
doing something more brilliant in this area, for those that wish to
switch between multiple installed versions, as he asked for a tracking
issue to be created, which I did.

Whether it will be exactly my technique, or something further improved,
time will tell. But that will only apply to versions released after 3.0
and 2.6.1 (unless he has already coded it into the release, but I doubt
he had time, or wishes to destabilize or delay these releases).

Anyway, if you remember the arcane techniques for copy/paste in CMD
prompt windows (Alt-space or click the "system" icon in the upper left
of the CMD prompt window), and go from there, then setting up the
multiple ftypes becomes a bit easier, perhaps.

 

[Colin J. Williams]

The equivalent of those commands is available via Windows Explorer,
Tools / Folder Options, File Types, scroll-scroll-scroll your way to
.py, Click Advanced, fiddle, copy paste apply, and other twaddle.

Yes, but what's needed is a further level of indirection. Currently,
this allows .py to be associated with a particular editor. It would be
great if there were some way of associating "Python.File", which is
created in the install process, with a particular editor. Then, one is
left with associating "Python.File" with a given version of Python.
Meanwhile, your suggestion provides a workaround.

Colin W.

 

[Glenn Linderman]

Yes, but what's needed is a further level of indirection. Currently,
this allows .py to be associated with a particular editor. It would
be great if there were some way of associating "Python.File", which is
created in the install process, with a particular editor. Then, one
is left with associating "Python.File" with a given version of
Python. Meanwhile, your suggestion provides a workaround.

Sure, it is possible to simply change the Python.File ftype -- just
issue the command

ftype Python.File="C:\PythonNN\python.exe" "%1" %*

for NN = 25, 26 or 30 or whatever. But that is longer and harder to
remember and type than the assoc which is why chose to keep three ftypes
around and switch between them with the assoc command. But if you put
them in a batch file, or shortcut, the length and complexity wouldn't be
as much of an issue. But changing one or changing the other is roughly
equivalent... ftype is an extra level of indirection over assoc... and
it is designed to allow programs that handle multiple extensions to not
proliferate the full command for each extensions. For example, a
multi-image-format image program, could use something like:

assoc .jpg=ImageProg.File
assoc .gif=ImageProg.File
assoc .tif=ImageProg.File
ftype ImageProg.file="C:\Program Files\ImageProg\ImageProg.exe" "%1" %*

In that situation, because of the potentially large number of
extensions, changing the assoc isn't equivalent to changing the ftype,
but for Python, I'm unaware of it needing to handle multiple extensions
from the command line or via double clicking in Explorer, so was
exploiting the extra level of indirection to save typing, and make the
command simpler to remember.

Not sure what your reference to an editor is about. ftype only fiddles
with the Shell Open command; if you want to do tricks with different
editors for different versions of Python, then you have to fiddle the
Shell Edit command; this can be done with clever manipulation of the
registry... it would be straightforward to create a .reg file that swaps
both the Shell Open and Shell Edit commands for different versions of
Python, if that is useful... and maybe it is if you use an IDE of some
sort. Since I just use emacs to edit .py files, I ignored the Shell
Edit command. Instead I have a Shell Emacs command that is set up to
apply to all file types, and is available via the context menu from
Windows Explorer... but I use that not only for different versions of
Python, but source code in other languages, and text files of all types.

 

[Martin v. Löwis]

I'm unaware of it needing to handle multiple extensions
from the command line or via double clicking in Explorer, so was
exploiting the extra level of indirection to save typing, and make the
command simpler to remember.

Python *does* provide multiple useful extensions that you might want to
double-click, namely .py and .pyw. It also provides an association for
..pyc; whether that is useful or not may be debatable.

Not sure what your reference to an editor is about.

This I also wonder about. Apparently, his editor has the capability of
running Python scripts, and then his question is how to make the editor
use a different Python version (and he assumed that there is the notion
of a "default" Python version in Windows, and that the editor would just
run the default).

I'm still very unsure as to what his editor actually does, but his
report of success seems to indicate that it choses the interpreter
associated with .py.

Regards,
Martin

 

[Colin J. Williams]

OK, Issue 4485 created. My first one, so let me know if I goofed. I
elaborated a bit from the original email, upon reflection. Seemed
useful, but also seemed complex by the time I got done.

I don't really have a clue what the uninstaller should do with these;
nor have I fiddled to know if it presently removes Python.File. I
suppose it should delete them, if and only if the ftype and assoc have
the same content as was created by the corresponding version installation.

Here's another approach to handling
multiple versions of Python, thanks to the
PyScripter List. It does not address
the need to access different versions of
the Python Interpreter.


Here is the full story.

There are two types of Python installation
a) For all users
Python creates registry entries at
HKEY_LOCAL_MACHINE\SOFTWARE\Python
\PythonCore\2.x with installation info
and puts the dll in c:\Windows
\System32.
b) For a single user
Python creates registry entries at
HKEY_CURRENT_USER\SOFTWARE\Python
\PythonCore\2.x with installation info
and does not put the dll in c:
\Windows\System32.

PyScripter without any command line
flags looks at the registry to
find the latest version of Python and
then for an all user
installation tries to load the relevant
Python dll from the system
path. For a single user installation
tries to load the DLL from the
Install path that is in the registry.

When PyScripter is used with a
--PYTHONxx flag then it does the above
but searching only for the specific version.
The Registry lookup does not take place
when Python is used with the --
PYTHONDLLPATH. Instead PyScripter tries
to load the Python dll from
the specified path.
The --PYTHONDLLPATH flag should be used
with the --PYTHONxx flag. See
http://pyscripter.googlepages.com/portablepython
for an example of
using PyScripter with portable Python.

The %PYTHONHOME% variable is not used by
PyScripter directly but by
Python to find the installed libraries.
See the Python documentation
for its use.

Colin W.

 

[Colin J. Williams]

OK, Issue 4485 created. My first one, so let me know if I goofed. I
elaborated a bit from the original email, upon reflection. Seemed
useful, but also seemed complex by the time I got done.

I don't really have a clue what the uninstaller should do with these;
nor have I fiddled to know if it presently removes Python.File. I
suppose it should delete them, if and only if the ftype and assoc have
the same content as was created by the corresponding version installation.

Here's another approach to handling
multiple versions of Python, thanks to the
PyScripter List. It does not address
the need to access different versions of
the Python Interpreter.


Here is the full story.

There are two types of Python installation
a) For all users
Python creates registry entries at
HKEY_LOCAL_MACHINE\SOFTWARE\Python
\PythonCore\2.x with installation info
and puts the dll in c:\Windows
\System32.
b) For a single user
Python creates registry entries at
HKEY_CURRENT_USER\SOFTWARE\Python
\PythonCore\2.x with installation info
and does not put the dll in c:
\Windows\System32.

PyScripter without any command line
flags looks at the registry to
find the latest version of Python and
then for an all user
installation tries to load the relevant
Python dll from the system
path. For a single user installation
tries to load the DLL from the
Install path that is in the registry.

When PyScripter is used with a
--PYTHONxx flag then it does the above
but searching only for the specific version.
The Registry lookup does not take place
when Python is used with the --
PYTHONDLLPATH. Instead PyScripter tries
to load the Python dll from
the specified path.
The --PYTHONDLLPATH flag should be used
with the --PYTHONxx flag. See
http://pyscripter.googlepages.com/portablepython
for an example of
using PyScripter with portable Python.

The %PYTHONHOME% variable is not used by
PyScripter directly but by
Python to find the installed libraries.
See the Python documentation
for its use.

Colin W.

 

[Wolfgang Strobl]

Glenn Linderman wrote:

This I also wonder about. Apparently, his editor has the capability of
running Python scripts, and then his question is how to make the editor
use a different Python version (and he assumed that there is the notion
of a "default" Python version in Windows, and that the editor would just
run the default).

If I'm not mistaken, he uses SciTE. That editor utilizes an config file
"python.properties", which contains the following section by default

if PLAT_WIN
command.go.*.py=pythonw -u "$(FileNameExt)"
command.go.subsystem.*.py=1
command.go.*.pyw=pythonw -u "$(FileNameExt)"
command.go.subsystem.*.pyw=1

Obviously, it just runs "pythonw" from the path, which points to
python25 containing Python2.5.2 on my system. So SciTE uses
Python2.5.2, here..

Changing SciTEs "python.properties" by replacing
command.go.*.py=pythonw -u "$(FileNameExt)"
with
command.go.*.py=c:\python26\pythonw -u "$(FileNameExt)"
runs files having a .py suffix through Python2.6, when using the "go"
command (F5) within SciTE.

Changing the path to pointing to python26, i.e.
C:\Python26>path=c:\python26;%path%
in a command window and then starting SciTE from within that shell has
the same effect, without changing "python.properties".

I'm still very unsure as to what his editor actually does, but his
report of success seems to indicate that it choses the interpreter
associated with .py.

SciTE doesn't do that, in the default configuration it just uses
whatever is called "pythonw" on the path, for running files having a .py
or .pyw suffix.