Creating C modules for Python under Cygwin

[Alex Martelli]

Martin v. Löwis wrote:

> Alex Martelli <aleax at aleax.it> writes:
> 
>> So, it's PERFECTLY feasible on Windows for a DLL to access symbols that
>> are defined in the executable that loads said DLL, by any of several
>> means.
> 
> That's very interesting indeed. In http://python.org/sf/551093, Jason
> Tischler argues that you absolutely must build Python with a shared
> Python DLL, or else it can't possibly work. I thought this was
> overstated, but didn't dare question the "common knowledge" that you
> can only link against DLLs, not executables.

I'm not sure what Cygwin or other versions of gcc for Windows can do.
With Microsoft Visual C++, the "common knowledge" is however misplaced.


>> I really can't see that.  A standalone python.exe might be less than
>> optimal for other reasons
> 
> I wonder what those "other reasons" could be, though. What exactly
> *is* the rationale for Python using a DLL on Windows?

A typical example of "a good reason to keep Python in a DLL" would be
if several different applications (.EXE's), not just Python.exe,
embedded Python.  With Python in a shared library, every extension
can be linked just once, against the DLL, and will be usable with any
application that embeds Python through that DLL.  If extensions were
linked against Python.EXE, they'd have to be relinked separately for
every embedding-application that wants to have those extensions
available.

I don't know if there are all that many .EXE's embedding Python on
Windows, nor if that was the reason for the (perfectly reasonable)
choice to build Python itself as a DLL there.  Just expounding on the
"less than optimal for other reasons" comment I made above -- I
realize not everybody's been "blessed" with doing systems-level
development and consulting on Windows for many years (how I pity you
all poor, deprived developers who had to stick to Linux, BSD, &c...!),
so these tradeoffs may be not clear at all to many readers, since they
_are_ quite different from those involved with .so's on Linux &c.


Alex