«

On 10/1/2012 12:02 PM, Alister wrote:
> On Sun, 30 Sep 2012 15:14:17 -0400, Edward Diener wrote:
>
>> 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.
>
> 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.

On 9/30/2012 3:38 PM, Andrew Berg wrote:
> On 2012.09.30 14:14, Edward Diener wrote:
>> 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.
>

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

On 05/10/2012 13:15, Edward Diener wrote:
> On 10/1/2012 12:02 PM, Alister wrote:
>> On Sun, 30 Sep 2012 15:14:17 -0400, Edward Diener wrote:
>>
>>> 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.
>>
>> 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.
>
>

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

--
Cheers.

Mark Lawrence.

On Fri, 05 Oct 2012 08:15:30 -0400, Edward Diener
<> declaimed the following in
gmane.comp.python.general:

>
> 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.
>>> ^Z


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".
--
Wulfraed Dennis Lee Bieber AF6VN
HTTP://wlfraed.home.netcom.com/

On 10/5/2012 5:32 PM, Dennis Lee Bieber wrote:
> On Fri, 05 Oct 2012 08:15:30 -0400, Edward Diener
> <> declaimed the following in
> gmane.comp.python.general:
>
>>
>> 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 ****

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.
>>>> ^Z
>
>
> 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.

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

On Sat, Oct 6, 2012 at 1:27 AM, <> wrote:
> 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.