[Pyrex] C-API implementation in Pyrex 0.9.6
Greg Ewing
greg.ewing at canterbury.ac.nz
Tue Oct 16 07:07:38 CEST 2007
Stefan Behnel wrote:
> 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.
What I had in mind with "public" is the situation where you
are putting together a single module that consists of some
parts written in Pyrex and some parts written in C. The
whole lot is just one dynamically-imported module, with the
parts glued together via normal C linking methods, either
static or shared. There's no need for dynamic importing of
types and functions in that case.
I'm still feeling my way with all this, though. I may end
up dropping the api keyword and just having a compiler
option for generating an api file containing everything
that is declared public, and maybe another one for treating
the whole .pxd file as public.
BTW, I've just added a feature that may help a bit in the
meantime. You can now factor out a 'cdef' and associated
extern/public/api attributes from a collection of declarations
and make a block out of them. So if you put the whole
contents of a .pxd file inside
cdef public api:
...
you'll get the behaviour you want, i.e. everything declared
in the .pxd is public and api-importable.
--
Greg
More information about the Pyrex
mailing list