Creating C modules for Python under Cygwin

[Alex Martelli]

Martin v. Loewis wrote:

> Alex Martelli <aleax at aleax.it> writes:
> 
>> 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.
> 
> I feel the choice of putting Python into a DLL is questionable,
> atleast for the following reasons:
> 
> - you force extension modules to tie themselves to a specific version
>   of the Python DLL. This means that there is zero chance that you can

That has nothing to do with the DLL - vs - EXE choice, as far as I can
see, and everything to do with the choice of NAME for the executable
module you package Python's functionality into.  If you named the EXE
PYTHON22.EXE and so on, you'd be "forcing extensions module" just as
much; vice versa, if you named the DLL PYTHON.DLL you would not be
forcing those modules to commit.  It's not about the extension:-),
it's about the filename.

>   exchange extension modules across Python releases - even though the
>   Python interpreter itself allows for such sharing (on other
>   platforms).
> 
> - when freezing Python applications, I would like to have a static
>   library, not a shared one, so that I get a stand-alone binary.

Yes, it IS unfortunate that (up to .NET excluded) Windows won't let
an EXE file physically embody the DLLs it needs.  Supplying a .LIB
for static linking in such special cases would be nice.  Of course,
extension modules would also have to be linked all together in this
case, or you still wouldn't get a stand-alone binary.  Since you do
need such special linking anyway for this case, it's not a problem,
I think, if said hypothetical .LIB is only used for sucn purposes
and not for 'normal', unfrozen cases.


> OTOH, the "we can embed Python" argument is not so strong as it may
> seem: when you embed Python, you still need some glue code for the
> container; that glue code could easily link with a static library,
> instead of a shared one. Of course, then the question is what to link
> extension modules against.

Of course.  If your embedded-Python EXE uses the same Python DLL as
ever other such EXEs, you don't need to relink extensions -- otherwise
you do.  Thus, not sure what you mean by 'not so strong as it may seem'.


Alex