Dag Sverre Seljebotn | 2 Mar 11:54 2011

Re: [Cython] Multiple modules in one compilation unit

On 03/02/2011 11:48 AM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 02.03.2011 11:20:
>> c) Somehow provide more than one module in the same compilation unit.
>> Again, this requires the build to work correctly, but seems less 
>> dangerous,
>> and also has the advantage of *allowing* static linking of the Fortran
>> library, if one wants to.
>> But is something like this possible? Could one implement
>> cython -o assembly.c file1.pyx file2.pyx file3.pyx
>> ...where assembly.so would contain three Python modules? (initfile1,
>> initfile2, and so on...)
> Can't currently work because the three modules would define the same 
> static C names. This could be fixed as part of the PEP 3121 
> implementation:
> http://trac.cython.org/cython_trac/ticket/173
> Or it could be worked around by overriding the prefixes in Naming.py 
> (which sounds ugly).
> Generally speaking, I'm -1 on this idea. I don't see a real use case, 
> and you're saying yourself that this isn't required to make your 
> Fortran use case work either.

But assuming work is spent on Cython, it *could* work? I.e. there's not 
a problem with import mechanisms; Python assumes one module per .so or 
similar? Or would one have to write a custom importer?

>> - If you build the Fortran code as a static library (rather common...),
>> then each pyx file will have their own copy. This will link successfully
>> but likely have a rather poor effect.
> So? lxml has two main modules, and if you build it statically against 
> libxml2/libxslt, you end up with two static versions of that library 
> in the two modules. Takes up some additional space, but otherwise 
> works beautifully.

Problem is that Fortran code often has...interesting...programming 
practices. Global variables abound, and are often initialised between 
modules. Imagine:

print compute_mod.get_alpha_squared()

This behaves quite differently with two static versions rather than one...

Dag Sverre