Coexistence of Python 2.x and 3.x on same OS

E

Edward Diener

Has there been any official software that allows both the Python 2.x and
3.x releases to coexist on the same OS so that the end-user can easily
switch between them when invoking Python scripts after each has been
installed to their own directories/folders ?

I know of some unoffical solutions, but they require lots of tweaks.
Given the vagaries of the different OSs on which Python can run I am
hoping for some offical solution which will work on any of the most
popular OSs ( Windows, Linux, Mac ).

The situation is so confusing on Windows, where the file associations,
registry entries, and other internal software which allows a given
Python release to work properly when invoking Python is so complicated,
that I have given up on trying to install more than one Python release
and finding a relaible, foolproof way of switching between them. So
although I would like to use the latest 3.x series on Windows I have
decide to stick with the latest 2.x series instead because much software
using Python does not support 3.x yet.
 
A

Andrew Berg

The situation is so confusing on Windows, where the file associations,
registry entries, and other internal software which allows a given
Python release to work properly when invoking Python is so complicated,
that I have given up on trying to install more than one Python release
and finding a relaible, foolproof way of switching between them. So
although I would like to use the latest 3.x series on Windows I have
decide to stick with the latest 2.x series instead because much software
using Python does not support 3.x yet.

http://www.python.org/dev/peps/pep-0397/

Unix-based OSes should already obey the shebang line, and on Windows,
there's py.exe in 3.3 that will launch the intended version based on
that shebang line. While I was using the alpha/beta versions of 3.3, I
had no problems invoking either 3.2 or 3.3 with the shebang line on Windows.
 
E

Edward Diener

http://www.python.org/dev/peps/pep-0397/

Unix-based OSes should already obey the shebang line, and on Windows,
there's py.exe in 3.3 that will launch the intended version based on
that shebang line.

The problem with that is that one has to already being using 3.3 to use
this facility. I was hoping for a solution which was backwards
compatible with Python 2.x.

My thought is a program distributed by Python which finds the versions
of Python on an OS, lets the end-user choose which version should be
invoked when Python is invoked, and does whatever is necessary to make
that version the default version.
While I was using the alpha/beta versions of 3.3, I
had no problems invoking either 3.2 or 3.3 with the shebang line on Windows.

That does not solve the problem for Python 2.x distributions.
 
A

Andrew Berg

The problem with that is that one has to already being using 3.3 to use
this facility. I was hoping for a solution which was backwards
compatible with Python 2.x.
It's a separate tool that comes with 3.3. You can install 3.3 and never
use the actual 3.3 interpreter if you wish.
That does not solve the problem for Python 2.x distributions.
Compatibility across versions of Python is irrelevant; the launcher
doesn't execute any Python code itself.
Straight from the PEP:
 
D

Dave Angel

The problem with that is that one has to already being using 3.3 to
use this facility. I was hoping for a solution which was backwards
compatible with Python 2.x.

My thought is a program distributed by Python which finds the versions
of Python on an OS, lets the end-user choose which version should be
invoked when Python is invoked, and does whatever is necessary to make
that version the default version.


That does not solve the problem for Python 2.x distributions.

If you read the Pep, it says the launcher will work for both 2.x and 3.x
http://www.python.org/dev/peps/pep-0397/
<http://www.python.org/dev/peps/pep-0397/>

I've read that elsewhere, but I can't see just where you would get the
necessary modules to run it with 2.x Possibly you'd have to build it
from sources, as there are Windows binaries that get installed to the
C:\Windows directory.
 
D

Dennis Lee Bieber

My thought is a program distributed by Python which finds the versions
of Python on an OS, lets the end-user choose which version should be
invoked when Python is invoked, and does whatever is necessary to make
that version the default version.
Which wouldn't be usable on any system that has to boot/process
unattended, and run's Python scripts for configuration set-up.

Making a version "default" pretty much means being able to rewrite
the PATH environment variable... And I've seen too many messes made by
some software already (including once having two generations of Python
showing up in one PATH!)
 
D

David Robinow

If you read the Pep, it says the launcher will work for both 2.x and 3.x
http://www.python.org/dev/peps/pep-0397/
<http://www.python.org/dev/peps/pep-0397/>

I've read that elsewhere, but I can't see just where you would get the
necessary modules to run it with 2.x Possibly you'd have to build it
from sources, as there are Windows binaries that get installed to the
C:\Windows directory.
I'm not sure what you're getting at here. The solution is to install
Python 3.3, which provides the launcher. It works with Python 2.x. Is
there some reason not to install 3.3?
 
E

Edward Diener

Which wouldn't be usable on any system that has to boot/process
unattended, and run's Python scripts for configuration set-up.

I can understand that but my use of Python on Windows is not that case.
I simply want to be able to choose which version of Python runs when it
is invoked, when I have multiple versions installed. Surely that is a
very common case for end-users running 'python' or invoking some script
which is associated with python.
Making a version "default" pretty much means being able to rewrite
the PATH environment variable... And I've seen too many messes made by
some software already (including once having two generations of Python
showing up in one PATH!)

The PATH environment is constantly changing whether in Linux or Windows.
Claiming that this is too dangerous" is silly.
 
E

Edward Diener

on my fedora system it was a simple matter of:-
#> yum install python3

to use python 3 i specify it in my shebang line

#!/usr/bun/env python3

Simple

Not sure about Windoze though (Although from memory the install asks
where to install so should not be a major issue)

Windows installs of Python do not distinguish releases by Pythonx(.x)
but just install different versions of Python in different directories.
However one can make links to the different versions based on their
release numbers, and that would allow a shebang line work if it was
supported.
 
E

Edward Diener

http://www.python.org/dev/peps/pep-0397/

Unix-based OSes should already obey the shebang line, and on Windows,
there's py.exe in 3.3 that will launch the intended version based on
that shebang line. While I was using the alpha/beta versions of 3.3, I
had no problems invoking either 3.2 or 3.3 with the shebang line on Windows.

Thanks ! I will get this and hopefully it will do what I want.
 
M

Mark Lawrence

Windows installs of Python do not distinguish releases by Pythonx(.x)
but just install different versions of Python in different directories.
However one can make links to the different versions based on their
release numbers, and that would allow a shebang line work if it was
supported.

Please read this http://www.python.org/dev/peps/pep-0397/ and let us
know whether or not it fits your needs on Windows.
 
D

Dennis Lee Bieber

Windows installs of Python do not distinguish releases by Pythonx(.x)
but just install different versions of Python in different directories.

Really?

E:\Python27>dir
Volume in drive E is Data
Volume Serial Number is 2626-D991

Directory of E:\Python27

08/28/2012 05:32 PM <DIR> .
08/28/2012 05:32 PM <DIR> ..
08/28/2012 02:11 PM <DIR> DLLs
08/28/2012 05:43 PM <DIR> Doc
08/28/2012 02:11 PM <DIR> include
08/31/2012 04:58 PM <DIR> Lib
08/28/2012 02:11 PM <DIR> libs
08/28/2012 02:15 PM 108,255 matplotlib-wininst.log
08/28/2012 02:18 PM 4,169 MySQL-python-wininst.log
08/28/2012 02:15 PM 98,498 numpy-wininst.log
08/28/2012 02:20 PM 17,816 PIL-wininst.log
08/28/2012 03:29 PM 1,572 PyOpenGL-accelerate-wininst.log
08/28/2012 03:38 PM 3,009 pyserial-wininst.log

06/24/2011 12:38 PM 27,136 python.exe ****
06/24/2011 12:38 PM 27,136 python2.7.exe ****
06/24/2011 12:38 PM 27,136 python2.exe ****

08/28/2012 05:32 PM 90,943 PythonCard-wininst.log

06/24/2011 12:38 PM 27,136 pythonw.exe ****
06/24/2011 12:38 PM 27,136 pythonw2.7.exe ****
06/24/2011 12:38 PM 27,136 pythonw2.exe ****

08/28/2012 02:15 PM 196,096 Removematplotlib.exe
08/28/2012 02:18 PM 196,096 RemoveMySQL-python.exe
08/28/2012 02:15 PM 196,096 Removenumpy.exe
08/28/2012 02:20 PM 196,096 RemovePIL.exe
08/28/2012 03:29 PM 196,096 RemovePyOpenGL-accelerate.exe
08/28/2012 03:38 PM 196,096 Removepyserial.exe
08/28/2012 05:32 PM 61,440 RemovePythonCard.exe
08/28/2012 02:20 PM 196,096 Removereportlab.exe
08/28/2012 02:19 PM 196,096 Removescipy.exe
08/28/2012 05:29 PM 196,096 RemoveWConio.exe
08/28/2012 02:20 PM 40,362 reportlab-wininst.log
08/28/2012 02:19 PM 159,420 scipy-wininst.log
08/28/2012 05:32 PM <DIR> Scripts
08/28/2012 02:11 PM <DIR> tcl
08/28/2012 02:11 PM <DIR> Tools
11/28/2007 04:32 PM 258,352 unicows.dll
06/24/2011 12:38 PM 49,664 w9xpopen.exe
08/28/2012 05:29 PM 891 WConio-wininst.log
28 File(s) 2,822,071 bytes
10 Dir(s) 148,557,684,736 bytes free

E:\Python27>

That's what was set up by a recent ActiveState installer (well,
recent for me -- I'd still been using 2.5 three months ago)

Yes, it IS in a version numbered directory, but there are copies of
the executable named as plain python, pythonX, and pythonX.Y

E:\Python27>cd %homepath%

E:\UserData\Wulfraed\My Documents>python
ActivePython 2.7.2.5 (ActiveState Software Inc.) based on
Python 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

E:\UserData\Wulfraed\My Documents>python2.7
ActivePython 2.7.2.5 (ActiveState Software Inc.) based on
Python 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Granted, one would need to have each installation directory in the
PATH, ordered such that the preferred version would be found first when
using just "python".
 
E

Edward Diener

Really?

E:\Python27>dir
Volume in drive E is Data
Volume Serial Number is 2626-D991

Directory of E:\Python27

08/28/2012 05:32 PM <DIR> .
08/28/2012 05:32 PM <DIR> ..
08/28/2012 02:11 PM <DIR> DLLs
08/28/2012 05:43 PM <DIR> Doc
08/28/2012 02:11 PM <DIR> include
08/31/2012 04:58 PM <DIR> Lib
08/28/2012 02:11 PM <DIR> libs
08/28/2012 02:15 PM 108,255 matplotlib-wininst.log
08/28/2012 02:18 PM 4,169 MySQL-python-wininst.log
08/28/2012 02:15 PM 98,498 numpy-wininst.log
08/28/2012 02:20 PM 17,816 PIL-wininst.log
08/28/2012 03:29 PM 1,572 PyOpenGL-accelerate-wininst.log
08/28/2012 03:38 PM 3,009 pyserial-wininst.log

06/24/2011 12:38 PM 27,136 python.exe ****
06/24/2011 12:38 PM 27,136 python2.7.exe ****
06/24/2011 12:38 PM 27,136 python2.exe ****

08/28/2012 05:32 PM 90,943 PythonCard-wininst.log

06/24/2011 12:38 PM 27,136 pythonw.exe ****
06/24/2011 12:38 PM 27,136 pythonw2.7.exe ****
06/24/2011 12:38 PM 27,136 pythonw2.exe ****

That's, as you say, ActievState. The normal Python installer does not
create a python2.7.exe etc.

But of course I can create any links I want, so that's not really the
problem. The major difficulty is that prior to invoking either "python"
directly or a script with a normal Python file association, I want to be
able to specify which version of Python should be invoked as the default
without having to specifically invoke a partiocular version by typing
'python2.7 ...' or 'python3.3 ...' etc.
08/28/2012 02:15 PM 196,096 Removematplotlib.exe
08/28/2012 02:18 PM 196,096 RemoveMySQL-python.exe
08/28/2012 02:15 PM 196,096 Removenumpy.exe
08/28/2012 02:20 PM 196,096 RemovePIL.exe
08/28/2012 03:29 PM 196,096 RemovePyOpenGL-accelerate.exe
08/28/2012 03:38 PM 196,096 Removepyserial.exe
08/28/2012 05:32 PM 61,440 RemovePythonCard.exe
08/28/2012 02:20 PM 196,096 Removereportlab.exe
08/28/2012 02:19 PM 196,096 Removescipy.exe
08/28/2012 05:29 PM 196,096 RemoveWConio.exe
08/28/2012 02:20 PM 40,362 reportlab-wininst.log
08/28/2012 02:19 PM 159,420 scipy-wininst.log
08/28/2012 05:32 PM <DIR> Scripts
08/28/2012 02:11 PM <DIR> tcl
08/28/2012 02:11 PM <DIR> Tools
11/28/2007 04:32 PM 258,352 unicows.dll
06/24/2011 12:38 PM 49,664 w9xpopen.exe
08/28/2012 05:29 PM 891 WConio-wininst.log
28 File(s) 2,822,071 bytes
10 Dir(s) 148,557,684,736 bytes free

E:\Python27>

That's what was set up by a recent ActiveState installer (well,
recent for me -- I'd still been using 2.5 three months ago)

Yes, it IS in a version numbered directory, but there are copies of
the executable named as plain python, pythonX, and pythonX.Y

E:\Python27>cd %homepath%

E:\UserData\Wulfraed\My Documents>python
ActivePython 2.7.2.5 (ActiveState Software Inc.) based on
Python 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

E:\UserData\Wulfraed\My Documents>python2.7
ActivePython 2.7.2.5 (ActiveState Software Inc.) based on
Python 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Granted, one would need to have each installation directory in the
PATH, ordered such that the preferred version would be found first when
using just "python".

There is much more than just the PATH needed to change to have a
different Python be the default. File associations also. I thnk there
are more things too, but I know it has always been difficult on Windows
to easily change which distribution is called when "python" is executed
or some Python file association is executed.

I welcome the new Python launcher for Windows mentioned but have not had
a chance to use it and see how it works yet. I will try it this weekend
and hopefully it will work well to solve the problem of having multiple
Python installations installed on Windows at the same time, and being
able to easily specify the one I want invoked.
 
W

wxjmfauth

Using Python on Windows is a dream.

Python uses and needs the system, but the system does
not use Python.

Every Python version is installed in its own isolated
space, site-packages included and without any defined
environment variable. Every Python can be seen as a
different application.
Knowing this, it is a no-problem to use the miscellaneous
versions; can be with the console, with an editor, with
..bat or .cmd files, with the Windows "start menu" launcher,
.... like any application.

The file extension is a double sword. Do not use it or
unregister it, the msi installer allows to do this.
It is the same task/problem as with any file, .txt, .png, ...

The new Python launcher is a redondant tool.

A point of view from a multi-users desktop user.

----

In my mind, it is a mistake to deliver a ready
preconfigurated installation.

"TeX" (I may say, as usual) is doing fine. A "TeX"
installation consists usually only in "TeX" engines
installation/configuration. It let the user work the
way he wishes.

jmf
 
I

Ian Kelly

Using Python on Windows is a dream.

Python uses and needs the system, but the system does
not use Python.

Every Python version is installed in its own isolated
space, site-packages included and without any defined
environment variable. Every Python can be seen as a
different application.
Knowing this, it is a no-problem to use the miscellaneous
versions; can be with the console, with an editor, with
.bat or .cmd files, with the Windows "start menu" launcher,
... like any application.

The file extension is a double sword. Do not use it or
unregister it, the msi installer allows to do this.
It is the same task/problem as with any file, .txt, .png, ...

The new Python launcher is a redondant tool.

Yes, because all scripts are only ever run by the person who wrote
them. The main benefit here is for distribution of Python scripts
with version requirements. Just because you can rely on your Python
installation to be in C:\Python27 doesn't mean you can rely on
somebody else's installation to be there, or on their file
associations to be configured for the correct version.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,050
Latest member
AngelS122

Latest Threads

Top