Author eryksun
Recipients Decorater, TBBle, docs@python, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Date 2017-03-20.10:11:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> It's inconsistent with the Linux experience of an all-users 
> installation

Yes, if you build with --enable-shared on Linux, then the shared libraries and are installed in /usr/local/lib. 

Currently there's no direct equivalent for 3.5+ on Windows. However, delay-loading the DLL is an alternative to a static import. At program startup, get the install path from the registry and load python3x.dll manually via LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH. Delayed loading automates calling GetProcAddress, so you get the flexibility of a dynamic import without losing the convenience of a static import.

> add all the Python install directories to my path to ensure the DLLs 
> are visible to applications that link against them

If the 32-bit DLL were distributed as, for example, python36-32.dll, then this would at least be reliable, albeit tedious. Using System32 and SysWOW64 handles this problem reliably via file-system redirection.

> all users to go in ``%SystemDrive%\Python{major}{minor}``

The change to use %ProgramFiles% for a machine installation and %LocalAppData% for a user installation locks down the discretionary file security. In contrast, the file security inherited from C:\ is permissive. It allows any authenticated user the right to modify the directory, subdirectories, and files. The only rights not granted are delete-child (meaningless since the user has delete access for all files) and the right to modify the file security.
Date User Action Args
2017-03-20 10:11:44eryksunsetrecipients: + eryksun, paul.moore, tim.golden, TBBle, docs@python, zach.ware, steve.dower, Decorater
2017-03-20 10:11:44eryksunsetmessageid: <>
2017-03-20 10:11:44eryksunlinkissue29844 messages
2017-03-20 10:11:43eryksuncreate