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

Discussion in 'Python' started by Edward Diener, Sep 30, 2012.

  1. 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.
     
    Edward Diener, Sep 30, 2012
    #1
    1. Advertising

  2. Edward Diener

    Andrew Berg Guest

    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
     
    Andrew Berg, Sep 30, 2012
    #2
    1. Advertising

  3. 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.
     
    Edward Diener, Oct 1, 2012
    #3
  4. Edward Diener

    Andrew Berg Guest

    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
     
    Andrew Berg, Oct 1, 2012
    #4
  5. Edward Diener

    Dave Angel Guest

    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
     
    Dave Angel, Oct 1, 2012
    #5
  6. 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.
     
    Mark Lawrence, Oct 1, 2012
    #6
  7. On Sun, 30 Sep 2012 23:06:04 -0400, Edward Diener
    <> 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
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Oct 1, 2012
    #7
  8. On Sun, Sep 30, 2012 at 11:55 PM, Dave Angel <> 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?
     
    David Robinow, Oct 1, 2012
    #8
  9. On 01/10/2012 20:36, David Robinow wrote:
    > On Sun, Sep 30, 2012 at 11:55 PM, Dave Angel <> 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.
     
    Mark Lawrence, Oct 1, 2012
    #9
  10. On 10/1/2012 1:32 PM, Dennis Lee Bieber wrote:
    > On Sun, 30 Sep 2012 23:06:04 -0400, Edward Diener
    > <> 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.
     
    Edward Diener, Oct 5, 2012
    #10
  11. 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.
     
    Edward Diener, Oct 5, 2012
    #11
  12. 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.
     
    Edward Diener, Oct 5, 2012
    #12
  13. 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.
     
    Mark Lawrence, Oct 5, 2012
    #13
  14. 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/
     
    Dennis Lee Bieber, Oct 5, 2012
    #14
  15. 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.
     
    Edward Diener, Oct 6, 2012
    #15
  16. Edward Diener

    Guest

    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
     
    , Oct 6, 2012
    #16
  17. Edward Diener

    Ian Kelly Guest

    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.
     
    Ian Kelly, Oct 7, 2012
    #17
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?S2V2aW4gQnVydG9u?=

    Visual Studio 2003 and 2005 coexistence.

    =?Utf-8?B?S2V2aW4gQnVydG9u?=, Sep 4, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    488
    Juan T. Llibre
    Sep 4, 2006
  2. ASP ASP.NET Coexistence

    , Jul 25, 2008, in forum: ASP .Net
    Replies:
    1
    Views:
    432
    Cowboy \(Gregory A. Beamer\)
    Jul 26, 2008
  3. Max2006

    ASP.NET Winforms and MVC coexistence

    Max2006, Apr 1, 2009, in forum: ASP .Net
    Replies:
    4
    Views:
    625
    Max2006
    Apr 9, 2009
  4. Michael Schuerig

    Debian: coexistence of debs and gems?

    Michael Schuerig, May 4, 2005, in forum: Ruby
    Replies:
    4
    Views:
    137
    Michael Schuerig
    May 5, 2005
  5. Matej Cepl
    Replies:
    0
    Views:
    100
    Matej Cepl
    Apr 4, 2007
Loading...

Share This Page