Etienne Fortin added the comment:
I replaced:
import importlib.machinery
loader = importlib.machinery.ExtensionFileLoader(name, path)
return loader.load_module()
With:
import importlib.machinery
loader = importlib.machinery.ExtensionFileLoader(modname, filename
Etienne Fortin added the comment:
Is it possible that the C runtime introduced with 2999226, which I believe is
the "universal runtime" Microsoft is trying to introduce, modified something
that makes importlib break on 3.5???
--
___
Pyth
Etienne Fortin added the comment:
The only dll / pyd files I have are all in pywin32. I don't have a build
environment for extensions. Can anyone provide me with a very simple extension
DLL with at least one exported attribute?
--
___
P
Etienne Fortin added the comment:
At this point I can't say if it's Windows only or if it affect all platform. I
can't even guarantee that it will appear on all Windows platform. On my
platform (see following), it doesn't work:
Windows 7 64 bits with updates 2999226 and 3
Etienne Fortin added the comment:
I suggest the test should use pywin32. The test script could be only:
import pywintypes
dir(pywintypes)
Testing for an attribute that is defined in the DLL would make it pass or fail.
--
___
Python tracker
<h
Etienne Fortin added the comment:
No the behavior only changed for 3.5. 3.4 works just fine.
--
___
Python tracker
<http://bugs.python.org/issue24748>
___
___
Etienne Fortin added the comment:
It is also possible that the root cause is related to Microsoft Windows Update
2999226 and/or 3065987. The behavior was the same between 3.4 and 3.5 on a
machine without these updates and is believed to have changed after the install
of these updates
New submission from Etienne Fortin:
The pywin32 package use imp.load_dynamic() to load a DLL with Windows specific
type. On Python 3.4+ imp.load_dynamic() point to the following code which use
the newer importlib module:
import importlib.machinery
loader
