[Pyrex] C-API implementation in Pyrex 0.9.6

[Stefan Behnel]

Stefan Behnel wrote:
> the C-API support has been rewritten for integration in Pyrex, but not much to
> the better. What it now does is: create a PyCObject for *every* exported
> function and put it into the module dict under the name of the original
> function. The advantage is that you can now take the module attribute value,
> extract the pointer and call a single function.
> 
> However, I think the current implementation is a bad idea, as it pollutes the
> module namespace. What a user see now is a lot of module attributes that are
> nicely named like functions, but that cannot be called. Also, this means that
> the C-level view on the module gets exposed to the Python level, which can be
> rather confusing, depending on the naming scheme(s) in use. And given the fact
> that C APIs tend to be larger and more redundant than Python APIs, e.g. to
> reflect different function signatures, this is not a problem that I would want
> to see ignored.

Another problem seems to be that the generated *_api.h file #includes the
normally generated header file of the module. This creates additional source
dependencies and currently makes my code fail to compile. I get loads of
errors about undefined names:

src/lxml/etree.h:428: error: expected specifier-qualifier-list before
'xmlXPathContext'
src/lxml/etree.h:454: error: expected specifier-qualifier-list before
'xmlXPathContext'
src/lxml/etree.h:471: error: expected specifier-qualifier-list before
'xmlXPathCompExpr'
[...]

This is due to missing cimports in the .pyx file that cimports the API, which
makes the generated .c file lack some header #includes. However, the missing
header files are not required for the API, they only touch internally used
objects that are not exported through the API but written into the module .h
file. So #including the module header bloats the API and requires unnecessary
imports on user side.

Greg, I'd really like to see this changed.

Stefan