[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