This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: installation order of 32bit and 64bit python seems to matter
Type: behavior Stage: resolved
Components: Installation, Windows Versions: Python 3.4
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: peter@psantoro.net, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2014-12-27 13:38 by peter@psantoro.net, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (2)
msg233131 - (view) Author: Peter Santoro (peter@psantoro.net) * Date: 2014-12-27 13:38
It appears that installation order matters when installing both 32bit and 64bit versions of Python.  If you install the 32bit version first, the 64bit version will uninstall the 32bit version.  Here are the steps I used:

1. Starting point (Windows 7 64bit with latest MS patches):
   Python 3.3.5 32bit (c:\bin32\python33, required for support of older systems that will be upgraded to 3.4.3 when it's available)
   Python 3.4.1 32bit (c:\bin32\python34)
   Python 3.4.1 64bit (c:\bin\python34, included in PATH)
2. Uninstalled
   Python 3.4.1 32bit - ran as expected
   Python 3.4.1 64bit - ran as expected
3. Attempted Install (32bit install before 64bit install)
   Python 3.4.2 32bit (c:\bin32\python34) - ran as expected
   Python 3.4.2 64bit (c:\bin\python34) - install dialog had red warning message at top stating that previous version will be uninstalled; if you continue, the 64bit install deletes the Python 3.4.2 32bit install
4. Work around installation order (64bit install before 32bit install):
   Python 3.4.2 64bit (c:\bin\python34) - ran as expected
   Python 3.4.2 32bit (c:\bin32\python34) - ran as expected

Notes:

I've reported other strange issues with multiple versions of python installed, but they were deemed different than the original reported bug and were not further discussed.  It's quite possible that the combination of python versions installed/uninstalled over time on this system has caused some bad/unexpected/untested state (e.g. Windows registry entries).
msg233135 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-12-27 15:46
I'm already quite keen to rename the registry key for 32-bit on Windows, since there are some places where that will cause conflicts. This won't be done for 3.4 though, as we don't have an active maintainer for the old installer (Martin is still building them, but not working on it). I haven't yet thought about how the updated keys should look, but when I get time to get back to the installer I'll try some things.

The 3.5 installer shouldn't have this issue as it will use product codes to detect other Python installations rather than registry keys.
History
Date User Action Args
2022-04-11 14:58:11adminsetgithub: 67309
2021-10-21 21:04:08zach.waresetstatus: open -> closed
resolution: out of date
stage: resolved
2014-12-27 15:46:35steve.dowersetmessages: + msg233135
2014-12-27 14:06:37tim.goldensetnosy: + tim.golden, zach.ware, steve.dower
components: + Windows
2014-12-27 13:38:30peter@psantoro.netcreate