[Pyrex] C-API implementation in Pyrex 0.9.6

[Stefan Behnel]

Greg Ewing wrote:
> Stefan Behnel wrote:
>> As I said, Pyrex doesn't currently allow me to distinguish between
>> public and
>> non-public attributes of extension types.
> 
> If you're exporting any fields of an extension type at all,
> you *have* to export all of them, so that client code can
> get the struct layout right.

But that's not a problem if the code uses a header file in the background. I
understand your objections to that, but it does have the advantage of making
it clear what the public C API is, as only those types, attributes and
functions would be defined in the .pxd file.


> If those fields are pointers or references to other extension
> types, you don't need to export the types of the things they
> refer to, but you need at least an opaque declaration for them --
> as with xmlDoc and xmlNode in the last example I posted.

I still think it would be cleaner if I could leave private attributes out of
the API specification completely. If they are not public, users should not be
bothered with them at all.

I do see the advantage of having Pyrex read the public .pxd to validate it
against the .pyx implementation, but I think the goal of describing a public
API explicitly is not well served by the current mechanism. I start getting a
strong feeling that the module .pxd file is too low-level for that.


> Looking at what I'm putting in the .h files, I've realised
> that there is some stuff in there which doesn't really need
> to be there, and I'm working on fixing that.

Thanks. As I said, everything that's not explicitly public, api, or declared
in a .pxd file should not go in there. You can well leave it to the user to
make enough declarations public to compile external sources.


> However, the
> generated code should at least compile and work correctly
> the way things are, if you declare things in the right places
> and cimport them where they're needed.

It compiles now, but it fails on the initial import. I have two modules,
"lxml.etree" and "lxml.objectify". The objectify module cimports (and imports)
the etree module. Given that the stacktrace mentions line 1 in objectify.pyx,
I would say it's the cimport that fails here. One more thing to fix...

Traceback (most recent call last):
    from lxml import objectify
  File "objectify.pyx", line 1, in objectify
ImportError: No module named etree

Stefan