Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Coexistence of Python 2.x and 3.x on same OS
Skip to first unread message
Edward Diener
Sep 30, 2012, 3:14:17 PM9/30/12
to
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.
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.
Andrew Berg
Sep 30, 2012, 3:38:00 PM9/30/12
to comp.lang.python
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/
> 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
Edward Diener
Sep 30, 2012, 11:06:04 PM9/30/12
to
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
> 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.
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.
Andrew Berg
Sep 30, 2012, 11:54:02 PM9/30/12
to comp.lang.python
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
> 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.
use the actual 3.3 interpreter if you wish.
> That does not solve the problem for Python 2.x distributions.
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.
Dave Angel
Sep 30, 2012, 11:55:05 PM9/30/12
to eldi...@tropicsoft.com, Edward Diener, pytho...@python.org
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
Mark Lawrence
Oct 1, 2012, 4:28:54 AM10/1/12
to pytho...@python.org
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
> 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.
>
available here https://bitbucket.org/vinay.sajip/pylauncher/downloads
--
Cheers.
Mark Lawrence.
Alister
Oct 1, 2012, 12:02:18 PM10/1/12
to
#> 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
Message has been deleted
David Robinow
Oct 1, 2012, 3:36:14 PM10/1/12
to pytho...@python.org
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.
>>...
>> 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
> 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.
Python 3.3, which provides the launcher. It works with Python 2.x. Is
there some reason not to install 3.3?
Mark Lawrence
Oct 1, 2012, 3:46:06 PM10/1/12
to pytho...@python.org
On 01/10/2012 20:36, David Robinow wrote:
> On Sun, Sep 30, 2012 at 11:55 PM, Dave Angel <d...@davea.name> 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.
>>> ...
>>> 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
>> 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?
>
https://bitbucket.org/vinay.sajip/pylauncher/downloads , you don't need
Python 3.3.
--
Cheers.
Mark Lawrence.
Edward Diener
Oct 5, 2012, 8:06:41 AM10/5/12
to
On 10/1/2012 1:32 PM, Dennis Lee Bieber wrote:
> On Sun, 30 Sep 2012 23:06:04 -0400, Edward Diener
> <eldi...@tropicsoft.invalid> declaimed the following in
> gmane.comp.python.general:
> 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 23:06:04 -0400, Edward Diener
> <eldi...@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
>
>> 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.
>>
> 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.
Edward Diener
Oct 5, 2012, 8:15:30 AM10/5/12
to
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.
Edward Diener
Oct 5, 2012, 8:16:36 AM10/5/12
to
On 9/30/2012 3:38 PM, Andrew Berg wrote:
Mark Lawrence
Oct 5, 2012, 8:29:13 AM10/5/12
to pytho...@python.org
know whether or not it fits your needs on Windows.
--
Cheers.
Mark Lawrence.
Message has been deleted
Edward Diener
Oct 5, 2012, 8:51:36 PM10/5/12
to
On 10/5/2012 5:32 PM, Dennis Lee Bieber wrote:
> On Fri, 05 Oct 2012 08:15:30 -0400, Edward Diener
>
> 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.
> On Fri, 05 Oct 2012 08:15:30 -0400, Edward Diener
> <eldi...@tropicsoft.invalid> declaimed the following in
> gmane.comp.python.general:
>
>>
> 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?
>> but just install different versions of Python in different directories.
>
>
> 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.
wxjm...@gmail.com
Oct 6, 2012, 3:27:41 AM10/6/12
to eldi...@tropicsoft.com
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
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
Ian Kelly
Oct 6, 2012, 11:13:24 PM10/6/12
to Python
On Sat, Oct 6, 2012 at 1:27 AM, <wxjm...@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
> 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.
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.
0 new messages