[Pyrex] C-API implementation in Pyrex 0.9.6

Stefan Behnel stefan_ml at behnel.de
Tue Oct 16 08:23:40 CEST 2007


Greg Ewing wrote:
> Stefan Behnel wrote:
>> When I add C methods to these, I get errors that they are "not previously
>> declared in definition part of extension type".
> 
> Adding C methods changes the layout of the type's vtable,
> which has the same implications as changing the struct
> layout. So importers need to know about all the C methods
> that a type has.

Hmm, so you have to make all C methods of a type public even if none of them
*is* public? How is that about a .pyx dependency?

Now I'm actually all for dropping the "public" business and only providing the
public mechanism...

Although, what about separating the public and non-public fields and methods
also in the type struct layout? Pyrex could put the public fields directly
into the type struct and provide a straight fixed-size pointer to a struct
with the private fields and methods (or NULL if there are none). Those whould
be easy to separate as Pyrex knows explicitly what is public and what isn't.
And since the private parts would only be used inside the same .pyx file (or
included files), they would not even have to end up in the header file and
Pyrex could just drop all knowledge about them when it's done with the .pyx.

And the subclassing problem would just go away as changes to the private part
would never impact the struct size of the public part of a type.

I think that would solve all our problems here.

Stefan



More information about the Pyrex mailing list