Martin v. Löwis added the comment: Here is the rationale:
1. py.exe is a 32-bit binary installed into C:\windows, see PEP 397. It's in C:\windows so that it will be on the path for both 32-bit and 64-bit processes. 2. py.exe is installed by multiple installers (both 32-bit and 64-bit, and multiple versions of Python) 3. to do proper reference counting of the installations, the SharedDLLRefcount component flag is enabled for the py.exe component. As a consequence, py.exe will be removed when the last Python installation is uninstalled from the system. 4. there are two different reference counters for a file on Windows: a 32-bit reference counter and a 64 bit reference counter. A 64-bit installer would manipulate the 64-bit counter, and a 32-bit installer would manipulate the 32-bit counter. 5. by default, this would lead to py.exe disappearing after this sequence of installation steps: * install 32-bit 3.3 * install 64-bit 3.4 * uninstall 64-bit 3.4 The 32-bit reference counter would still be 1, but the 64-bit uninstallation would only look at the 64-bit counter, removing the file 6. to prevent that, the component is marked as 64-bit even for the 32-bit installer, to manipulate the 64-bit reference counter. The code contains a comment # XXX does this still allow to install the component on a 32-bit system? I never got to test this out of lack of a 32-bit Windows installation, apparently, it doesn't work. As a work-around, the 32-bit installer could include an additional component installing py.exe, which would be a 32-bit component and be selected if the host system is 32-bit. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21427> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com