[Pyrex] C-API implementation in Pyrex 0.9.6

Stefan Behnel stefan_ml at behnel.de
Thu Oct 11 19:00:47 CEST 2007


Hi,

the C-API support has been rewritten for integration in Pyrex, but not much to
be 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.

My original implementation was targeted to avoid exactly this problem, as it
exported only a single PyCObject as entry point that pointed to a function
table mapping string names to function pointers. It would have been easy to
generate the import code based on this table instead, which would have
provided the same level of binary independence.

Greg, is there any chance you could revert your changes to make the generated
modules less ugly and confusing?

Stefan




More information about the Pyrex mailing list