Eryk Sun added the comment:
> 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
libpython3.X.so.1.0 and libpython3.so 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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29844>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
