Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #30562 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  Coexistence of Python 2.x and 3.x on same OS Edward Diener <eldiener@tropicsoft.invalid> - 2012-09-30 15:14 -0400
    Re: Coexistence of Python 2.x and 3.x on same OS Andrew Berg <bahamutzero8825@gmail.com> - 2012-09-30 14:38 -0500
      Re: Coexistence of Python 2.x and 3.x on same OS Edward Diener <eldiener@tropicsoft.invalid> - 2012-09-30 23:06 -0400
        Re: Coexistence of Python 2.x and 3.x on same OS Andrew Berg <bahamutzero8825@gmail.com> - 2012-09-30 22:54 -0500
        Re: Coexistence of Python 2.x and 3.x on same OS Dave Angel <d@davea.name> - 2012-09-30 23:55 -0400
        Re: Coexistence of Python 2.x and 3.x on same OS Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-10-01 09:28 +0100
        Re: Coexistence of Python 2.x and 3.x on same OS Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-01 13:32 -0400
          Re: Coexistence of Python 2.x and 3.x on same OS Edward Diener <eldiener@tropicsoft.invalid> - 2012-10-05 08:06 -0400
        Re: Coexistence of Python 2.x and 3.x on same OS David Robinow <drobinow@gmail.com> - 2012-10-01 15:36 -0400
        Re: Coexistence of Python 2.x and 3.x on same OS Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-10-01 20:46 +0100
      Re: Coexistence of Python 2.x and 3.x on same OS Edward Diener <eldiener@tropicsoft.invalid> - 2012-10-05 08:16 -0400
    Re: Coexistence of Python 2.x and 3.x on same OS Alister <alister.ware@ntlworld.com> - 2012-10-01 16:02 +0000
      Re: Coexistence of Python 2.x and 3.x on same OS Edward Diener <eldiener@tropicsoft.invalid> - 2012-10-05 08:15 -0400
        Re: Coexistence of Python 2.x and 3.x on same OS Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-10-05 13:29 +0100
        Re: Coexistence of Python 2.x and 3.x on same OS Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-05 17:32 -0400
          Re: Coexistence of Python 2.x and 3.x on same OS Edward Diener <eldiener@tropicsoft.invalid> - 2012-10-05 20:51 -0400
    Re: Coexistence of Python 2.x and 3.x on same OS wxjmfauth@gmail.com - 2012-10-06 00:27 -0700
      Re: Coexistence of Python 2.x and 3.x on same OS Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-06 21:13 -0600

#30562 — Coexistence of Python 2.x and 3.x on same OS

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.

[toc] | [next] | [standalone]

#30564

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.
-- 
CPython 3.3.0 | Windows NT 6.1.7601.17835

[toc] | [prev] | [next] | [standalone]

#30588

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.

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.

[toc] | [prev] | [next] | [standalone]

#30591

On 2012.09.30 22:06, Edward Diener wrote:
> 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:
> The launcher is not tied to a specific version of Python - eg., a
> launcher distributed with Python 3.3 should be capable of locating and
> executing any Python 2.x and Python 3.x version.

-- 
CPython 3.3.0 | Windows NT 6.1.7601.17835

[toc] | [prev] | [next] | [standalone]

#30592

On 09/30/2012 11:06 PM, Edward Diener wrote:
> 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.
>
> 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.
>

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.

-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#30600

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

You don't need 3.3 to get py.exe.  I've been running it for months, it's 
available here https://bitbucket.org/vinay.sajip/pylauncher/downloads

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#30620

On Sun, 30 Sep 2012 23:06:04 -0400, Edward Diener
<eldiener@tropicsoft.invalid> declaimed the following in
gmane.comp.python.general:


> 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!)

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#30807

On 10/1/2012 1:32 PM, Dennis Lee Bieber wrote:
> On Sun, 30 Sep 2012 23:06:04 -0400, Edward Diener
> <eldiener@tropicsoft.invalid> declaimed the following in
> gmane.comp.python.general:
>
>
>> 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.

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.

[toc] | [prev] | [next] | [standalone]

#30622

On Sun, Sep 30, 2012 at 11:55 PM, Dave Angel <d@davea.name> wrote:
>> 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.
>>...
>> 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.
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?

[toc] | [prev] | [next] | [standalone]

#30623

On 01/10/2012 20:36, David Robinow wrote:
> On Sun, Sep 30, 2012 at 11:55 PM, Dave Angel <d@davea.name> wrote:
>>> 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.
>>> ...
>>> 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.
> 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?
>

Fo those who missed it earlier you can download the launcher here 
https://bitbucket.org/vinay.sajip/pylauncher/downloads , you don't need 
Python 3.3.

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#30809

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.

[toc] | [prev] | [next] | [standalone]

#30614

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)



-- 
Immortality consists largely of boredom.
		-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8

[toc] | [prev] | [next] | [standalone]

#30808

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.

[toc] | [prev] | [next] | [standalone]

#30810

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.

[toc] | [prev] | [next] | [standalone]

#30842

On Fri, 05 Oct 2012 08:15:30 -0400, Edward Diener
<eldiener@tropicsoft.invalid> 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
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#30856

On 10/5/2012 5:32 PM, Dennis Lee Bieber wrote:
> On Fri, 05 Oct 2012 08:15:30 -0400, Edward Diener
> <eldiener@tropicsoft.invalid> 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.

[toc] | [prev] | [next] | [standalone]

#30872

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

[toc] | [prev] | [next] | [standalone]

#30905

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web