[Cython] Gsoc project

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Thu Mar 29 05:28:54 CEST 2012

On 03/28/2012 07:58 PM, Philip Herron wrote:
> Hey all
> I am implemented a very crude and simplistic and very badly programmed
> version of a pxd generator i think i understand what were after now
> but i would appreciate if you look over what i did to make sure i have
> grasped the basic idea for now:
> So if i have:
> #include "test.h"
> int add (int x, int y)
> {
>    return x + y;
> }
> #ifndef __TEST_H__
> #define __TEST_H__
> extern int add (int, int);
> struct foobar {
>    int a;
>    unsigned char * b;
> };
> #endif //__TEST_H_
> We run gcc -fplugin=./python.so -fplugin-arg-python-script=walk.py test.c
> And i output out.pxd:
> cdef extern from "test.h":
> 	int add (int, int)
> 	ctypedef struct foobar:
> 		int a
> 		unsigned char * b

Nice. But please use 4 spaces (see PEP 8) :-)

More ideas for project proposal:

Another slight complication is that you should ideally turn

#define FOO 3
#define BAR 4


cdef extern from "foo.h":

so you need to hook in before the preprocessor and after the 
preprocessor and dig out different stuff.

Then what happens if you have

#ifdef FOO
#define BAR 3
#define BAR 4

?? I'm not saying it is hard, but perhaps no longer completely trivial :-)

And like Robert hinted at, supporting all the aspects of C++ might take 
a little more work, there's just so much different syntax in C++, and 
there's several C++ features Cython just does not support and must be 
either ignored or hacked around (e.g., "const").

Supporting stuff like

#define MACRO(x) ((x)->field*2)

probably belongs in the category of "must be done manually".

> So far in a very crude way it understands structs and functions but
> nothing else i can see how it could all work but i see now why you see
> it could be a very small project David's plugin system has mostly
> everything done for you but i would like to add to his plugin for some
> tree access code etc...
> Adding a config file for telling the plugin to not care about certain
> things would be a nice addition. It seems interesting the clang idea,
> it could be interesting porting this to other front-ends of gcc like
> gccgo.

Does gccgo use the C ABI so that Cython could call it? If so, go for it!

(Fortran is actually very much in use in the Cython userbase and would 
get a lot more "customers" than Go, but if you have more of a CS 
background or similar I can see why you wouldn't be so interested in 
Fortran. I didn't believe people were still using Fortran either until I 
started doing astrophysics, and suddenly it seems to be the default tool 
everybody uses for everything.)


More information about the cython-devel mailing list