Multiple Versions of Python on Windows XP

Discussion in 'Python' started by Colin J. Williams, Dec 2, 2008.

  1. Could anyone please point me to
    documentation on the way the msi
    installer handles multiple versions eg.
    Python 2.5, 2.6 and 3.0?

    What changes are made to the registry?

    Is there some way to specify a default
    version in such a way that it can be
    changed as necessary?

    PyScripter uses an option to select a
    version eg.

    C:\Program
    Files\PyScripter\PyScripter.exe --python26

    but I'm having some trouble with it when
    I attempt edit a python file from the
    Windows Explorer.

    I would appreciate any information.

    Colin W.
     
    Colin J. Williams, Dec 2, 2008
    #1
    1. Advertising

  2. > Could anyone please point me to documentation on the way the msi
    > installer handles multiple versions eg. Python 2.5, 2.6 and 3.0?


    I don't think that is documented anywhere.

    > What changes are made to the registry?


    For a complete list, see Tools/msi/msi.py in the source tree.

    > Is there some way to specify a default version in such a way that it can
    > be changed as necessary?


    What do you mean by "default version"?

    There is the version that is associated with the .py/.pyc extensions
    at any point in time; you can change these by re-running the respective
    installers from add-and-remove-programs. In a well-managed installation,
    only one Python installation would have the "Register Extensions"
    feature selected; to then change the default, one would unselect the
    feature in one version, and reselect it in a different. If only the
    default installation procedure was ever used, re-running the installer
    in "Repair" mode (from ARP) will also restore the extension
    associations.

    > PyScripter uses an option to select a version eg.
    >
    > C:\Program Files\PyScripter\PyScripter.exe --python26
    >
    > but I'm having some trouble with it when I attempt edit a python file
    > from the Windows Explorer.


    It would be good to be more specific with such statements: what troubles
    specifically? If I play dumb, I'd say "of course - windows explorer
    doesn't support editing Python files; you need a text editor".

    Regards,
    Martin
     
    Martin v. Löwis, Dec 2, 2008
    #2
    1. Advertising

  3. On approximately 12/1/2008 11:05 PM, came the following characters from
    the keyboard of Martin v. Löwis:
    >> Is there some way to specify a default version in such a way that it can
    >> be changed as necessary?
    >>

    >
    > What do you mean by "default version"?
    >
    > There is the version that is associated with the .py/.pyc extensions
    > at any point in time; you can change these by re-running the respective
    > installers from add-and-remove-programs. In a well-managed installation,
    > only one Python installation would have the "Register Extensions"
    > feature selected; to then change the default, one would unselect the
    > feature in one version, and reselect it in a different. If only the
    > default installation procedure was ever used, re-running the installer
    > in "Repair" mode (from ARP) will also restore the extension
    > associations.


    That seems a lot more cumbersome than just using the command line to
    change the ftype and assoc a bit. Here's how I set up my computer, for
    multiple versions. Now to change the "default", I just use the assoc
    command to change the association for .py to one of the three listed
    ftypes. Simple and quick.

    c:\>ftype Python25.File
    ftype Python25.File
    Python25.File="C:\Python25\python.exe" "%1" %*

    c:\>ftype Python26.File
    ftype Python26.File
    Python26.File="C:\Python26\python.exe" "%1" %*

    c:\>ftype Python30.File
    ftype Python30.File
    Python30.File="C:\Python30\python.exe" "%1" %*

    c:\>assoc .py
    assoc .py
    ..py=Python25.File


    It would be nice if the ftypes were version specific as created by the
    installer; IIRC, I created the above three from the ftype Python.File as
    I installed each version.

    --
    Glenn -- http://nevcal.com/
    ===========================
    A protocol is complete when there is nothing left to remove.
    -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
     
    Glenn Linderman, Dec 2, 2008
    #3
  4. > It would be nice if the ftypes were version specific as created by the
    > installer; IIRC, I created the above three from the ftype Python.File as
    > I installed each version.


    That's a good idea; please submit a wish list item to bugs.python.org.
    There may be issues (such as people relying on this being Python.File),
    but I can't see any problems off-hand.

    Regards,
    Martin
     
    Martin v. Löwis, Dec 2, 2008
    #4
  5. On approximately 12/1/2008 11:29 PM, came the following characters from
    the keyboard of Martin v. Löwis:
    >> It would be nice if the ftypes were version specific as created by the
    >> installer; IIRC, I created the above three from the ftype Python.File as
    >> I installed each version.
    >>

    >
    > That's a good idea; please submit a wish list item to bugs.python.org.
    > There may be issues (such as people relying on this being Python.File),
    > but I can't see any problems off-hand.
    >
    > Regards,
    > Martin
    >


    OK, Issue 4485 created. My first one, so let me know if I goofed. I
    elaborated a bit from the original email, upon reflection. Seemed
    useful, but also seemed complex by the time I got done.

    I don't really have a clue what the uninstaller should do with these;
    nor have I fiddled to know if it presently removes Python.File. I
    suppose it should delete them, if and only if the ftype and assoc have
    the same content as was created by the corresponding version installation.

    --
    Glenn -- http://nevcal.com/
    ===========================
    A protocol is complete when there is nothing left to remove.
    -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
     
    Glenn Linderman, Dec 2, 2008
    #5
  6. > OK, Issue 4485 created. My first one, so let me know if I goofed. I
    > elaborated a bit from the original email, upon reflection. Seemed
    > useful, but also seemed complex by the time I got done.


    Looks about right to me.

    > I don't really have a clue what the uninstaller should do with these;
    > nor have I fiddled to know if it presently removes Python.File. I
    > suppose it should delete them, if and only if the ftype and assoc have
    > the same content as was created by the corresponding version installation.


    The uninstaller will currently just remove it all. Conditional removal
    of the associations will be tricky; I'll look into it.

    I also wonder whether assoc only changes the settings for the current
    user. In that case, uninstalling a Python version that was per-machine
    would not affect the user's association, anyway.

    Regards,
    Martin
     
    Martin v. Löwis, Dec 2, 2008
    #6
  7. Martin v. Löwis wrote:
    >> Could anyone please point me to documentation on the way the msi
    >> installer handles multiple versions eg. Python 2.5, 2.6 and 3.0?

    >
    > I don't think that is documented anywhere.
    >
    >> What changes are made to the registry?

    >
    > For a complete list, see Tools/msi/msi.py in the source tree.


    I have scanned the file:
    http://svn.python.org/projects/python/branches/py3k/Tools/msi/msi.py

    I don't find anything that addresses
    this issue.

    >
    >> Is there some way to specify a default version in such a way that it can
    >> be changed as necessary?

    >
    > What do you mean by "default version"?


    I am seeking some mechanism such that
    any of Python 2.5, Python 2.6 or Python
    2.6 can be chosen as the currently
    active version.

    >
    > There is the version that is associated with the .py/.pyc extensions
    > at any point in time; you can change these by re-running the respective
    > installers from add-and-remove-programs. In a well-managed installation,
    > only one Python installation would have the "Register Extensions"
    > feature selected; to then change the default, one would unselect the
    > feature in one version, and reselect it in a different. If only the
    > default installation procedure was ever used, re-running the installer
    > in "Repair" mode (from ARP) will also restore the extension
    > associations.


    I was hoping that there is some simpler
    way than the "Repair" procedure.

    >
    >> PyScripter uses an option to select a version eg.
    >>
    >> C:\Program Files\PyScripter\PyScripter.exe --python26
    >>
    >> but I'm having some trouble with it when I attempt edit a python file
    >> from the Windows Explorer.

    >
    > It would be good to be more specific with such statements: what troubles
    > specifically? If I play dumb, I'd say "of course - windows explorer
    > doesn't support editing Python files; you need a text editor".


    Yes, I should have been clearer. The
    PyScripter application locks up and must
    be killed, using the Task Manager.

    Many thanks for your response.

    Best wishes,

    Colin W.
    >
    > Regards,
    > Martin
     
    Colin J. Williams, Dec 2, 2008
    #7
  8. >>> What changes are made to the registry?
    >>
    >> For a complete list, see Tools/msi/msi.py in the source tree.

    >
    > I have scanned the file:
    > http://svn.python.org/projects/python/branches/py3k/Tools/msi/msi.py
    >
    > I don't find anything that addresses this issue.


    Read the add_registry function. You may need to first understand
    how the Registry table in an MSI file works.

    > I am seeking some mechanism such that any of Python 2.5, Python 2.6 or
    > Python 2.6 can be chosen as the currently active version.


    If Glenn Lindermann's answer doesn't help, you need to explain:
    what is a "currently active version"? How is one Python version
    more active than any other?

    > I was hoping that there is some simpler way than the "Repair" procedure.


    See Glenn Lindermann's answer.

    >> It would be good to be more specific with such statements: what troubles
    >> specifically? If I play dumb, I'd say "of course - windows explorer
    >> doesn't support editing Python files; you need a text editor".

    >
    > Yes, I should have been clearer. The PyScripter application locks up
    > and must be killed, using the Task Manager.


    I think you need to report that to the PyScripter authors as a bug.
    I can't imagine how the "currently active version" can affect what
    PyScripter does.

    Regards,
    Martin
     
    Martin v. Löwis, Dec 2, 2008
    #8
  9. Martin v. Löwis wrote:
    >>>> What changes are made to the registry?
    >>> For a complete list, see Tools/msi/msi.py in the source tree.

    >> I have scanned the file:
    >> http://svn.python.org/projects/python/branches/py3k/Tools/msi/msi.py
    >>
    >> I don't find anything that addresses this issue.

    >
    > Read the add_registry function. You may need to first understand
    > how the Registry table in an MSI file works.
    >
    >> I am seeking some mechanism such that any of Python 2.5, Python 2.6 or
    >> Python 2.6 can be chosen as the currently active version.

    >
    > If Glenn Lindermann's answer doesn't help, you need to explain:
    > what is a "currently active version"? How is one Python version
    > more active than any other?
    >
    >> I was hoping that there is some simpler way than the "Repair" procedure.

    >
    > See Glenn Lindermann's answer.


    I'll look at it
    >
    >>> It would be good to be more specific with such statements: what troubles
    >>> specifically? If I play dumb, I'd say "of course - windows explorer
    >>> doesn't support editing Python files; you need a text editor".


    Using a right click, one can open any
    ..py file with say SciTe. Within SciTe,
    one can Run the current file.

    It would be good to have the appropriate
    version (my use of "default") preselected.

    >> Yes, I should have been clearer. The PyScripter application locks up
    >> and must be killed, using the Task Manager.

    >
    > I think you need to report that to the PyScripter authors as a bug.
    > I can't imagine how the "currently active version" can affect what
    > PyScripter does.


    Yes, I'll do that.

    >


    I'll also follow up with Glenn
    Lindermann's answer.

    Many thanks,

    Best wishes,

    Colin W.
    > Regards,
    > Martin
     
    Colin J. Williams, Dec 2, 2008
    #9
  10. > Using a right click, one can open any .py file with say SciTe. Within
    > SciTe, one can Run the current file.
    >
    > It would be good to have the appropriate version (my use of "default")
    > preselected.


    I don't know how SciTe choses the version of Python to run. In the
    sense in why you use the word, there might just not be a "default"
    version of Python on Windows. Somebody who knows SciTe better may
    correct me.

    Regards,
    Martin
     
    Martin v. Löwis, Dec 2, 2008
    #10
  11. Hi!

    Multiple versions of Python is possible (example: Python standard +
    Python by OOo).
    But, multiple versions of Python+PyWin32 is not possible.

    Suggestion: use VirtualBox or Virtual-PC.

    @-salutations
    --
    Michel Claveau
     
    Méta-MCI (MVP), Dec 2, 2008
    #11
  12. On Dec 1, 4:49 pm, "Colin J. Williams" <> wrote:
    > Could anyone please point me to
    > documentation on the way the msi
    > installer handles multiple versions eg.
    > Python 2.5, 2.6 and 3.0?
    >
    > What changes are made to the registry?
    >
    > Is there some way to specify a default
    > version in such a way that it can be
    > changed as necessary?
    >
    > PyScripter uses an option to select a
    > version eg.
    >
    > C:\Program
    > Files\PyScripter\PyScripter.exe --python26
    >
    > but I'm having some trouble with it when
    > I attempt edit a python file from the
    > Windows Explorer.
    >
    > I would appreciate any information.
    >
    > Colin W.


    Some more factoids that may be of use:

    1. The last Python you install will take over all the file
    associations, start menu stuff, etc.
    2. You can enumerate over the Pythons you have installed in \
    \HKEY_LOCAL_MACHINE\Software\Python\PythonCore\
    3. If you silently install a Python PACKAGE made with distutils'
    bdist_msi, it will by default install to the latest Python version it
    finds (2.6 > 2.5 > 2.4 > 2.3)
     
    Jason Scheirer, Dec 2, 2008
    #12
  13. Martin v. Löwis wrote:
    >>>> What changes are made to the registry?
    >>> For a complete list, see Tools/msi/msi.py in the source tree.

    >> I have scanned the file:
    >> http://svn.python.org/projects/python/branches/py3k/Tools/msi/msi.py
    >>
    >> I don't find anything that addresses this issue.

    >
    > Read the add_registry function. You may need to first understand
    > how the Registry table in an MSI file works.
    >
    >> I am seeking some mechanism such that any of Python 2.5, Python 2.6 or
    >> Python 2.6 can be chosen as the currently active version.

    >
    > If Glenn Lindermann's answer doesn't help, you need to explain:
    > what is a "currently active version"? How is one Python version
    > more active than any other?
    >
    >> I was hoping that there is some simpler way than the "Repair" procedure.

    >
    > See Glenn Lindermann's answer.
    >
    >>> It would be good to be more specific with such statements: what troubles
    >>> specifically? If I play dumb, I'd say "of course - windows explorer
    >>> doesn't support editing Python files; you need a text editor".

    >> Yes, I should have been clearer. The PyScripter application locks up
    >> and must be killed, using the Task Manager.

    >
    > I think you need to report that to the PyScripter authors as a bug.
    > I can't imagine how the "currently active version" can affect what
    > PyScripter does.
    >
    > Regards,
    > Martin


    Martin,

    Many thanks for your responses. Yes,
    Glen Lindermann's suggestion seems to
    meet the need.

    It's been a while since I've looked at
    DOS and I didn't remember fType or assoc.

    Michel Claveau suggests VirtualBox, this
    seems a big hammer to kill
    this particular fly.

    It's interesting that each install sets
    up a Python.File variable in the registry.

    It's a pity that this can't be used to
    achieve this more simply.

    Best wishes,

    Colin W.
     
    Colin J. Williams, Dec 3, 2008
    #13
  14. On approximately 12/3/2008 8:51 AM, came the following characters from
    the keyboard of Colin J. Williams:
    > Martin v. Löwis wrote:
    >>>>> What changes are made to the registry?
    >>>> For a complete list, see Tools/msi/msi.py in the source tree.
    >>> I have scanned the file:
    >>> http://svn.python.org/projects/python/branches/py3k/Tools/msi/msi.py
    >>>
    >>> I don't find anything that addresses this issue.

    >>
    >> Read the add_registry function. You may need to first understand
    >> how the Registry table in an MSI file works.
    >>
    >>> I am seeking some mechanism such that any of Python 2.5, Python 2.6 or
    >>> Python 2.6 can be chosen as the currently active version.

    >>
    >> If Glenn Lindermann's answer doesn't help, you need to explain:
    >> what is a "currently active version"? How is one Python version
    >> more active than any other?
    >>
    >>> I was hoping that there is some simpler way than the "Repair"
    >>> procedure.

    >>
    >> See Glenn Lindermann's answer.
    >>
    >>>> It would be good to be more specific with such statements: what
    >>>> troubles
    >>>> specifically? If I play dumb, I'd say "of course - windows explorer
    >>>> doesn't support editing Python files; you need a text editor".
    >>> Yes, I should have been clearer. The PyScripter application locks up
    >>> and must be killed, using the Task Manager.

    >>
    >> I think you need to report that to the PyScripter authors as a bug.
    >> I can't imagine how the "currently active version" can affect what
    >> PyScripter does.
    >>
    >> Regards,
    >> Martin

    >
    > Martin,
    >
    > Many thanks for your responses. Yes,
    > Glen Lindermann's suggestion seems to
    > meet the need.
    >
    > It's been a while since I've looked at
    > DOS and I didn't remember fType or assoc.


    The equivalent of those commands is available via Windows Explorer,
    Tools / Folder Options, File Types, scroll-scroll-scroll your way to
    ..py, Click Advanced, fiddle, copy paste apply, and other twaddle. A
    perfect example of why not everything should be done via GUI interfaces,
    or at least why this is an extremely poor GUI interface.

    GUI designers should count the command line keystrokes, and make sure
    their interface is shorter, otherwise they are a failure.

    > Michel Claveau suggests VirtualBox, this
    > seems a big hammer to kill
    > this particular fly.
    >
    > It's interesting that each install sets
    > up a Python.File variable in the registry.
    >
    > It's a pity that this can't be used to achieve this more simply.


    Martin seems willing to entertain the idea of future Windows installers
    doing something more brilliant in this area, for those that wish to
    switch between multiple installed versions, as he asked for a tracking
    issue to be created, which I did.

    Whether it will be exactly my technique, or something further improved,
    time will tell. But that will only apply to versions released after 3.0
    and 2.6.1 (unless he has already coded it into the release, but I doubt
    he had time, or wishes to destabilize or delay these releases).

    Anyway, if you remember the arcane techniques for copy/paste in CMD
    prompt windows (Alt-space or click the "system" icon in the upper left
    of the CMD prompt window), and go from there, then setting up the
    multiple ftypes becomes a bit easier, perhaps.

    > Best wishes,
    >
    > Colin W.




    --
    Glenn -- http://nevcal.com/
    ===========================
    A protocol is complete when there is nothing left to remove.
    -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
     
    Glenn Linderman, Dec 4, 2008
    #14
  15. Glenn Linderman wrote:
    >
    > The equivalent of those commands is available via Windows Explorer,
    > Tools / Folder Options, File Types, scroll-scroll-scroll your way to
    > .py, Click Advanced, fiddle, copy paste apply, and other twaddle.

    Yes, but what's needed is a further level of indirection. Currently,
    this allows .py to be associated with a particular editor. It would be
    great if there were some way of associating "Python.File", which is
    created in the install process, with a particular editor. Then, one is
    left with associating "Python.File" with a given version of Python.
    Meanwhile, your suggestion provides a workaround.

    Colin W.
    > A perfect example of why not everything should be done via GUI
    > interfaces, or at least why this is an extremely poor GUI interface.
    >
    > GUI designers should count the command line keystrokes, and make sure
    > their interface is shorter, otherwise they are a failure.
    >
    >> Michel Claveau suggests VirtualBox, this
    >> seems a big hammer to kill
    >> this particular fly.
    >>
    >> It's interesting that each install sets
    >> up a Python.File variable in the registry.
    >>
    >> It's a pity that this can't be used to achieve this more simply.

    >
    > Martin seems willing to entertain the idea of future Windows
    > installers doing something more brilliant in this area, for those that
    > wish to switch between multiple installed versions, as he asked for a
    > tracking issue to be created, which I did.
    >
    > Whether it will be exactly my technique, or something further
    > improved, time will tell. But that will only apply to versions
    > released after 3.0 and 2.6.1 (unless he has already coded it into the
    > release, but I doubt he had time, or wishes to destabilize or delay
    > these releases).
    >
    > Anyway, if you remember the arcane techniques for copy/paste in CMD
    > prompt windows (Alt-space or click the "system" icon in the upper left
    > of the CMD prompt window), and go from there, then setting up the
    > multiple ftypes becomes a bit easier, perhaps.
    >
    >> Best wishes,
    >>
    >> Colin W.

    >
    >
    >
     
    Colin J. Williams, Dec 4, 2008
    #15
  16. On approximately 12/4/2008 5:29 AM, came the following characters from
    the keyboard of Colin J. Williams:
    >
    >
    > Glenn Linderman wrote:
    >>
    >> The equivalent of those commands is available via Windows Explorer,
    >> Tools / Folder Options, File Types, scroll-scroll-scroll your way to
    >> .py, Click Advanced, fiddle, copy paste apply, and other twaddle.

    > Yes, but what's needed is a further level of indirection. Currently,
    > this allows .py to be associated with a particular editor. It would
    > be great if there were some way of associating "Python.File", which is
    > created in the install process, with a particular editor. Then, one
    > is left with associating "Python.File" with a given version of
    > Python. Meanwhile, your suggestion provides a workaround.


    Sure, it is possible to simply change the Python.File ftype -- just
    issue the command

    ftype Python.File="C:\PythonNN\python.exe" "%1" %*

    for NN = 25, 26 or 30 or whatever. But that is longer and harder to
    remember and type than the assoc which is why chose to keep three ftypes
    around and switch between them with the assoc command. But if you put
    them in a batch file, or shortcut, the length and complexity wouldn't be
    as much of an issue. But changing one or changing the other is roughly
    equivalent... ftype is an extra level of indirection over assoc... and
    it is designed to allow programs that handle multiple extensions to not
    proliferate the full command for each extensions. For example, a
    multi-image-format image program, could use something like:

    assoc .jpg=ImageProg.File
    assoc .gif=ImageProg.File
    assoc .tif=ImageProg.File
    ftype ImageProg.file="C:\Program Files\ImageProg\ImageProg.exe" "%1" %*

    In that situation, because of the potentially large number of
    extensions, changing the assoc isn't equivalent to changing the ftype,
    but for Python, I'm unaware of it needing to handle multiple extensions
    from the command line or via double clicking in Explorer, so was
    exploiting the extra level of indirection to save typing, and make the
    command simpler to remember.

    Not sure what your reference to an editor is about. ftype only fiddles
    with the Shell Open command; if you want to do tricks with different
    editors for different versions of Python, then you have to fiddle the
    Shell Edit command; this can be done with clever manipulation of the
    registry... it would be straightforward to create a .reg file that swaps
    both the Shell Open and Shell Edit commands for different versions of
    Python, if that is useful... and maybe it is if you use an IDE of some
    sort. Since I just use emacs to edit .py files, I ignored the Shell
    Edit command. Instead I have a Shell Emacs command that is set up to
    apply to all file types, and is available via the context menu from
    Windows Explorer... but I use that not only for different versions of
    Python, but source code in other languages, and text files of all types.

    --
    Glenn -- http://nevcal.com/
    ===========================
    A protocol is complete when there is nothing left to remove.
    -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
     
    Glenn Linderman, Dec 5, 2008
    #16
  17. Glenn Linderman wrote:
    > I'm unaware of it needing to handle multiple extensions
    > from the command line or via double clicking in Explorer, so was
    > exploiting the extra level of indirection to save typing, and make the
    > command simpler to remember.


    Python *does* provide multiple useful extensions that you might want to
    double-click, namely .py and .pyw. It also provides an association for
    ..pyc; whether that is useful or not may be debatable.

    > Not sure what your reference to an editor is about.


    This I also wonder about. Apparently, his editor has the capability of
    running Python scripts, and then his question is how to make the editor
    use a different Python version (and he assumed that there is the notion
    of a "default" Python version in Windows, and that the editor would just
    run the default).

    I'm still very unsure as to what his editor actually does, but his
    report of success seems to indicate that it choses the interpreter
    associated with .py.

    Regards,
    Martin
     
    Martin v. Löwis, Dec 6, 2008
    #17
  18. Glenn Linderman wrote:
    > On approximately 12/1/2008 11:29 PM, came the following characters from
    > the keyboard of Martin v. Löwis:
    >>> It would be nice if the ftypes were version specific as created by the
    >>> installer; IIRC, I created the above three from the ftype Python.File as
    >>> I installed each version.
    >>>

    >>
    >> That's a good idea; please submit a wish list item to bugs.python.org.
    >> There may be issues (such as people relying on this being Python.File),
    >> but I can't see any problems off-hand.
    >>
    >> Regards,
    >> Martin
    >>

    >
    > OK, Issue 4485 created. My first one, so let me know if I goofed. I
    > elaborated a bit from the original email, upon reflection. Seemed
    > useful, but also seemed complex by the time I got done.
    >
    > I don't really have a clue what the uninstaller should do with these;
    > nor have I fiddled to know if it presently removes Python.File. I
    > suppose it should delete them, if and only if the ftype and assoc have
    > the same content as was created by the corresponding version installation.
    >


    Here's another approach to handling
    multiple versions of Python, thanks to the
    PyScripter List. It does not address
    the need to access different versions of
    the Python Interpreter.


    Here is the full story.

    There are two types of Python installation
    a) For all users
    Python creates registry entries at
    HKEY_LOCAL_MACHINE\SOFTWARE\Python
    \PythonCore\2.x with installation info
    and puts the dll in c:\Windows
    \System32.
    b) For a single user
    Python creates registry entries at
    HKEY_CURRENT_USER\SOFTWARE\Python
    \PythonCore\2.x with installation info
    and does not put the dll in c:
    \Windows\System32.

    PyScripter without any command line
    flags looks at the registry to
    find the latest version of Python and
    then for an all user
    installation tries to load the relevant
    Python dll from the system
    path. For a single user installation
    tries to load the DLL from the
    Install path that is in the registry.

    When PyScripter is used with a
    --PYTHONxx flag then it does the above
    but searching only for the specific version.
    The Registry lookup does not take place
    when Python is used with the --
    PYTHONDLLPATH. Instead PyScripter tries
    to load the Python dll from
    the specified path.
    The --PYTHONDLLPATH flag should be used
    with the --PYTHONxx flag. See
    http://pyscripter.googlepages.com/portablepython
    for an example of
    using PyScripter with portable Python.

    The %PYTHONHOME% variable is not used by
    PyScripter directly but by
    Python to find the installed libraries.
    See the Python documentation
    for its use.

    Colin W.
     
    Colin J. Williams, Dec 6, 2008
    #18
  19. Glenn Linderman wrote:
    > On approximately 12/1/2008 11:29 PM, came the following characters from
    > the keyboard of Martin v. Löwis:
    >>> It would be nice if the ftypes were version specific as created by the
    >>> installer; IIRC, I created the above three from the ftype Python.File as
    >>> I installed each version.
    >>>

    >>
    >> That's a good idea; please submit a wish list item to bugs.python.org.
    >> There may be issues (such as people relying on this being Python.File),
    >> but I can't see any problems off-hand.
    >>
    >> Regards,
    >> Martin
    >>

    >
    > OK, Issue 4485 created. My first one, so let me know if I goofed. I
    > elaborated a bit from the original email, upon reflection. Seemed
    > useful, but also seemed complex by the time I got done.
    >
    > I don't really have a clue what the uninstaller should do with these;
    > nor have I fiddled to know if it presently removes Python.File. I
    > suppose it should delete them, if and only if the ftype and assoc have
    > the same content as was created by the corresponding version installation.
    >


    Here's another approach to handling
    multiple versions of Python, thanks to the
    PyScripter List. It does not address
    the need to access different versions of
    the Python Interpreter.


    Here is the full story.

    There are two types of Python installation
    a) For all users
    Python creates registry entries at
    HKEY_LOCAL_MACHINE\SOFTWARE\Python
    \PythonCore\2.x with installation info
    and puts the dll in c:\Windows
    \System32.
    b) For a single user
    Python creates registry entries at
    HKEY_CURRENT_USER\SOFTWARE\Python
    \PythonCore\2.x with installation info
    and does not put the dll in c:
    \Windows\System32.

    PyScripter without any command line
    flags looks at the registry to
    find the latest version of Python and
    then for an all user
    installation tries to load the relevant
    Python dll from the system
    path. For a single user installation
    tries to load the DLL from the
    Install path that is in the registry.

    When PyScripter is used with a
    --PYTHONxx flag then it does the above
    but searching only for the specific version.
    The Registry lookup does not take place
    when Python is used with the --
    PYTHONDLLPATH. Instead PyScripter tries
    to load the Python dll from
    the specified path.
    The --PYTHONDLLPATH flag should be used
    with the --PYTHONxx flag. See
    http://pyscripter.googlepages.com/portablepython
    for an example of
    using PyScripter with portable Python.

    The %PYTHONHOME% variable is not used by
    PyScripter directly but by
    Python to find the installed libraries.
    See the Python documentation
    for its use.

    Colin W.
     
    Colin J. Williams, Dec 6, 2008
    #19
  20. "Martin v. Löwis" <>:

    >Glenn Linderman wrote:


    >> Not sure what your reference to an editor is about.

    >
    >This I also wonder about. Apparently, his editor has the capability of
    >running Python scripts, and then his question is how to make the editor
    >use a different Python version (and he assumed that there is the notion
    >of a "default" Python version in Windows, and that the editor would just
    >run the default).


    If I'm not mistaken, he uses SciTE. That editor utilizes an config file
    "python.properties", which contains the following section by default

    if PLAT_WIN
    command.go.*.py=pythonw -u "$(FileNameExt)"
    command.go.subsystem.*.py=1
    command.go.*.pyw=pythonw -u "$(FileNameExt)"
    command.go.subsystem.*.pyw=1

    Obviously, it just runs "pythonw" from the path, which points to
    python25 containing Python2.5.2 on my system. So SciTE uses
    Python2.5.2, here..

    Changing SciTEs "python.properties" by replacing
    command.go.*.py=pythonw -u "$(FileNameExt)"
    with
    command.go.*.py=c:\python26\pythonw -u "$(FileNameExt)"
    runs files having a .py suffix through Python2.6, when using the "go"
    command (F5) within SciTE.

    Changing the path to pointing to python26, i.e.
    C:\Python26>path=c:\python26;%path%
    in a command window and then starting SciTE from within that shell has
    the same effect, without changing "python.properties".

    >
    >I'm still very unsure as to what his editor actually does, but his
    >report of success seems to indicate that it choses the interpreter
    >associated with .py.


    SciTE doesn't do that, in the default configuration it just uses
    whatever is called "pythonw" on the path, for running files having a .py
    or .pyw suffix.

    --
    Wir danken für die Beachtung aller Sicherheitsbestimmungen
     
    Wolfgang Strobl, Dec 6, 2008
    #20
    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. Edwin Young
    Replies:
    3
    Views:
    352
    Edwin Young
    Jun 7, 2004
  2. Steven Bethard
    Replies:
    0
    Views:
    310
    Steven Bethard
    Dec 2, 2004
  3. Nicolas Fleury
    Replies:
    4
    Views:
    442
    Greg Ewing
    Mar 21, 2005
  4. Max M
    Replies:
    1
    Views:
    414
    Brandon K
    Oct 10, 2005
  5. Replies:
    2
    Views:
    3,861
    Fuzzyman
    Feb 24, 2006
Loading...

Share This Page