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.
> 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.
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
> 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.
> 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.
> 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.
> 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.
>> 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.
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.
> 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.
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)
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?
> 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?
> On Sun, 30 Sep 2012 23:06:04 -0400, Edward Diener
> <eldie...@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.
> 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 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.
> 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 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.
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.
> 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.
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.
On Sat, Oct 6, 2012 at 1:27 AM, <wxjmfa...@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.
