[Pyrex] [Cython-dev] cdef private class ... ?

Stefan Behnel stefan_ml at behnel.de
Thu Jan 31 08:24:54 CET 2008


Hi Greg,

Greg Ewing wrote:
> Stefan Behnel wrote:
>> Actually, you could still allow that for the C-API, which could add public
>> types to the "_pyx_capi" dict
> 
> That's possible, although it would make things a bit weird
> for non-Pyrex extension modules to deal with.

Hmm, why is that? I imagine it this way:

- Private types do not end up in the module dictionary and therefore do not
become visible to Python code. The main reasoning behind this is the factory
pattern, which (I imagine) is used fairly often for extension types anyway. At
least lxml makes heavy use of it for Python proxies of XML nodes, which need
an injected pointer to C structs, and thus cannot be instantiated from Python
code anyway.

- All types that are declared in the module.pxd file (whether private or not)
get exported at the C level. They are stored in the _pyx_api dict, from where
extensions can import them (and only from there, a generated import function
should hide the internals here).

- Private types that are not declared in the associated .pxd file are not "C
public" and must not be used by foreign C code either.

I'm not sure if I want to additionally export all non-private Types (whether
declared in a .pxd or not), as it currently works. I could also imagine making
the export of private, non-pxd-declared types explicit, i.e. exporting only
those types that are either declared in the module.pxd or that are explicitly
marked "api". In any case, all exported types must use the same export/import
mechanism through _pyc_capi as the .pxd exported types.

What do you think about that?

Stefan


PS: It might be an error if a type is C-exported while its parents are not.
However, I would imagine we could also get by with 'wrapping' the non-public
parents into the type itself and just export the combined structure. But
that's a different battle field, I guess.



More information about the Pyrex mailing list