[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