On 10/11/07, Stefan Behnel <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]
> http://lists.copyleft.no/mailman/listinfo/pyrex
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
