[Pyrex] C-API implementation in Pyrex 0.9.6

[William Stein]

On 10/11/07, Stefan Behnel <stefan_ml at behnel.de> wrote:
> the C-API support has been rewritten for integration in Pyrex, but not much to
...

Hi,

Can I ask a few naive questions about "the C-API support", since I know that
me and _many_ of the people I work with are confused about what this support
provides?  I'll just ask a few naive questions, and maybe your answers would
be useful for me to add to the faq or documentation.

(1) Suppose I would like to define a cdef'd function in a module
arith.pyx that I want
to call from other .pyx files, e.g.,

cdef int fast_gcd(int a, int b):
   ...

Then I basically want to do this sort of thing from other .pyx files:
    from arith cimport fast_gcd
    int x = fast_gcd(5,7)

Definitely in Cython/Pyrex a few months ago the above wouldn't work.
Is there a way to make it work now?  And if so, what are the linking
requirements
(i.e. options to gcc or distutils)?

(2) Suppose I want to define a cdef'd function in a .pyx file, as above, but now
I want it to be callable from some external C file.  E.g.,

/* this is a C function in a .c file */
   int foo(blah) {
       fast_gcd(...)
   }

This is very natural to do because I might be mixing C and .pyx code,
and this provides a way to reach back and get at Python data directly
from C code.   Is there now a way to do this?

-- William

>
> 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
>
>
> _______________________________________________
> Pyrex mailing list
> Pyrex at lists.copyleft.no
> http://lists.copyleft.no/mailman/listinfo/pyrex
>


-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org