When does a binary extension gets the file extension '.pyd' and when is it '.so'

[Fredrik Lundh]

Steve Holden wrote:

> You display your ignorance here. The ".pyd" extension is used on Windows 
> as an alternative to ".dll", but both are recognized as shared 
> libraries. Personally I'm not really sure why they even chose to use 
> ".pyd", which is confusing to most Windows users. In UNIX/Linux 
> environments ".so" is the standard extension for a shared library.

background:

http://mail.python.org/pipermail/python-dev/1999-December/001456.html

"Python cannot import every .dll file.  Only .dll files that conform to
the convention for Python extension modules can be imported.  (The
convention is that it must export an init<module> function.)

On most other platforms, shared libraries must have a specific
extension (e.g. .so on most Unix).  Python allows you to drop such a
file into any directory where is looks for modules, and it will then
direct the dynamic load support to load that specific file.

This seems logical -- Python extensions must live in directories that
Python searches (Python must do its own search because the search
order is significant).

On Windows, Python uses the same strategy.  The only modification is
that it is allowed to give the file a different extension, namely
.pyd, to indicate that this really is a Python extension and not a
regular DLL.  This was mostly introduced because it is apparently
common to have an existing DLL "foo.dll" and write a Python wrapper
for it that is also called "foo".  Clearly, two files foo.dll are too
confusing, so we let you name the wrapper foo.pyd.  But because the
file format is essentially that of a DLL, we don't *require* this
renaming; some ways of creating DLLs in the first place may make it
difficult to do."

</F>