[Pyrex] C-API implementation in Pyrex 0.9.6

[Stefan Behnel]

Greg Ewing wrote:
> Another couple of reasons for keeping the .c files self-contained:
> 
> * The .pyx files can be processed in any order. Otherwise,
> if foo.pyx cimported from spam.pxd, you would have to
> process spam.pyx before compiling the .c file generated
> from foo.pyx. This would be an odd sort of dependency.

But it would be the expected order. Normally, I would expect to have a main
module with a public API that other modules connect to. I think the case where
two modules use the public API of each other should be so rare that I would
file it under "bad design".

Another expected use case would be that I distribute my
module/package/whatever and let users interface with it. So I build mine first
and then others build their modules against my distribution. No problem here
either.


> * It avoids any problems with modules that cimport from
> each other. Otherwise you could end up with two .h files
> that tried to #include each other, which would be quite
> a bad thing.

The generated module .h file doesn't currently include anything, so I can't
see why that should become a problem.

Stefan