Are *.pyd's universal?
Steven D'Aprano
steve at REMOVE-THIS-cybersource.com.au
Sat Oct 31 20:43:17 EDT 2009
On Sat, 31 Oct 2009 23:58:33 +1300, Lawrence D'Oliveiro wrote:
> In message <mailman.2365.1256979069.2807.python-list at python.org>, Albert
> Hopkins wrote:
>
>> On Sat, 2009-10-31 at 21:32 +1300, Lawrence D'Oliveiro wrote:
>>
>>In message
>><6e603d9c-2be0-449c-9c3c-bab49e09e8fc at 13g2000prl.googlegroups.com>, Carl
>>Banks wrote:
>>
>>> Modules will sometimes find themselves on the path in Windows, so the
>>> fact that Windows performs a library search on the path is quite
>>> significant.
>>>
>>> Why is it only Windows is prone to this problem?
I question your assumption. "DLL hell" is merely a platform-specific name
for a particular variety of a broader class of problems, namely
dependency conflicts and the bootstrapping problem. It's not even
specific to software -- bootstrapping problems are well known in many
fields of endeavour: before you can make the tools to make things, you
need to make the tools to make the tools...
It is far from true to say that Windows is the only system subject to
this problem.
http://en.wikipedia.org/wiki/Dependency_hell
Python, like most (all?) programming languages, has it's own version of
dependency hell, namely circular imports: module A depends on module B,
which depends on module C, which depends on module A...
Python also has a second "DLL Hell", as many newbies discover: shadowing
standard library modules. Create a module (say) "random.py" in the
current directory, and then try to import the standard library random.
This is a form of DLL Hell, because Python uses standard library modules
dynamically, importing them at runtime.
One solution to dependency conflicts and circular dependencies is to
avoid dependencies altogether. At the cost of disk space and memory, use
static linking and give up the benefits of dynamic libraries. Platforms
that encourage static linking avoid the DLL conflicts, but at the cost of
increased memory and storage usage, and static applications need to be
upgraded individually instead of merely upgrading the shared library.
>> I think as someone pointed out earlier, in Unix-like operating systems,
>> a "regular" library's file name starts with "lib", e.g. libcrypt.so.
>> So this would not conflict with Python's crypt.so.
But it would conflict with a Python module libcrypt.so if the PYTHONPATH
and the OS's shared library path coincided.
> I just checked my Debian installation:
>
> ldo at theon:~> find /lib /usr/lib -name \*.so -a -not -name lib\*
> -print | wc -l 2950
> ldo at theon:~> find /lib /usr/lib -name \*.so -print | wc -l 4708
>
> So 63% of the shareable libraries on my system have names NOT beginning
> with lib.
53% on my system. This just goes to show that even Linux developers often
don't bother with the conventions for their platforms.
--
Steven
More information about the Python-list
mailing list