[Pyrex] C-API implementation in Pyrex 0.9.6

Stefan Behnel stefan_ml at behnel.de
Mon Oct 15 18:09:06 CEST 2007


Greg Ewing wrote:
> Stefan Behnel wrote:
>> On the
>> other hand, Pyrex distinguishes between a C code API and a Pyrex code
>> API. I
>> don't see why.
> 
> I prefer it if the generated C code is self-contained when
> not interfacing with non-Pyrex code. If cimporting relied
> on .h files, there would be more files to keep track of

The .h file would be generated, no problem here.


> and issues of making sure the C compiler can find the .h
> files, etc.

We were discussing something like this on the Cython list lately (you don't
seem to be subscribed to the list). I think public .pxd files should just get
installed into a directory in the manner of /usr/include, maybe some special
/usr/share/pyrex-include directory, where they are globally available and
where Pyrex would search them by default.


> Also there are two different ways of connecting functions with
> external C code now, "public" and "api". Somehow you have to
> say which you want. You may not want the overhead of the
> api mechanism when you're not going to use it.

Maybe we should just drop the original behaviour of "public". I can't think of
many reasons why you should not just rely on "runtime C-importing" separate
modules.

I'm all for keeping the Pyrex-level and C-level interfaces identical and just
generate both automatically. There is no reason why you should prevent users
from interfacing with your Pyrex module in plain C, neither is there a reason
why you should enforce it. So you would always use both API mechanisms at the
same time anyway.

Stefan



More information about the Pyrex mailing list