Are *.pyd's universal?

[Steven D'Aprano]

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