[Pyrex] C-API implementation in Pyrex 0.9.6

[Greg Ewing]

Stefan Behnel wrote:
> 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.

I still think it would make the dependencies too convoluted.
It would mean that if foo.pyx imports spam.pxd, then foo.c
depends not only on spam.pxd but spam.pyx as well.

The .pxd is supposed to contain everything that matters to
the outside world, so that you can always change spam.pyx
without worrying that anything else will become out of date.

The situation is no worse than it is in C, where a struct
defined in a .h has to define all its fields, whether they
are conceptually regarded as public or not.

I appreciate that it would be nice if Pyrex could do better,
but even if it did, the dependency would still be there,
i.e. if you change anything that alters the layout of an
extension type, you *will* have to recompile all other modules
that either cimport it or use the C API. There's no getting
around that, and I prefer to make it obvious and explicit
rather than having it be a potential source of hidden
pitfalls.

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

Can you send me some actual code to try? I have no idea
what is going on there.

BTW, I have set up a Mercurial repository in my source tree
and I've been committing the last few changes into it. Where
should I go from here? What's the best way of making it
available to you and others?

--
Greg