Nathaniel Smith <n...@pobox.com> added the comment:

Putting .dll's next to their .pyd's isn't a general solution, because sometimes 
you want to be able to use the same .dll's from .pyd's that are in different 
directories. For example, scipy.spatial.qhull, scipy.optimize._lbfsgb, and 
scipy.linalg._flinalg are three different extensions in different directories, 
but they all link against BLAS. And you definitely don't want to include 
multiple copies of BLAS; the current scipy wheels on Linux are 50 MB, and 40 MB 
of that is *one* copy of OpenBLAS.

I don't think import hooks are terribly relevant here either. The big problem 
is how to arrange for the .dlls to be loaded before the .pyds. The obvious hack 
would be to somehow automatically rewrite the package __init__.py to either 
mutate PATH or pre-load the .dlls, which is admittedly pretty nasty. But... if 
you want to install an import hook, then that *also* requires rewriting the 
package __init__.py to inject the import hook installation code, and then the 
import hook would just be mutating PATH or pre-loading the .dlls. So adding an 
import hook to the mix doesn't seem to be buying much.

I guess I can see the argument for @xoviat's original proposal: if lots of 
packages are going to have weird code injected into their __init__.py just to 
add the same paths to the DLL search path, then maybe it's simpler all around 
if this becomes a standard feature of the Python importer. However, even if 
this were implemented we'd still need to write and maintain the __init__.py 
injection code for the next ~5 years, so probably the thing to do is to 
implement the __init__.py approach first and wait to see how it shakes out 
before considering interpreter changes.

----------
nosy: +njs

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to