On Oct 17, 2008, at 11:15 PM, Andrey Ivanov wrote: > Hello Cython developers, > > recently I started to refactor my C++/Python project, where I used > a SWIG tool > to build extention, and I discovered that Pyrex/Cython tool is much > more faster > and eats less memory. But there are some cons, it cannot create > shadow C++ > classes automaticly, so user must write them by hands. Of course > this is needed > base functionality for such tools, but it is not what developers > want (lazy, > like me :) ).
Actually, a lot of people do want this, but it's just that there are other things we want more, and we have limited time :). Personally, I tend to wrap more C than C++ code, and find the interface I want to provide to Python is not necessarily the "raw" interface as given by the underlying library, but this would certainly come in handy. And it could certainly be useful for C as well as C++. > So I've decided make an addition to Cython tool to provide such > functionality. > Because I'm not very experienced in how Pyrex/Cython works (and > there are some > specific, because tool must parse .h) I've decided to write > preprocessor wich > would roll out simple modified 'extern from' construction. It > integrates with > Cython in Utils.py module (by ihooks) and provides preprocessed > files instead > of original ones. Hopefully you'll be able to contribute directly to Cython itself. My one concern is that I don't want to add pyparsing as a dependancy, but the parser we ship with should be flexible enough for our needs. > There are a few constructions parsed by preprocessor I'm not quite sure exactly what you're explaining here--is the part above the line your input, and the part below autogenerated? > (I called it ccython because of lack of imagination): > > cdef extern from "China.hpp" import Dress, Phone: > pass > ------------------------- > cdef extern from "China.hpp": > ctypedef struct c_Dress "Dress": > void tearAtaTouch(); > c_Dress *new_Dress "new Dress" () > void del_Dress "delete" (c_Dress * ptr) > ctypedef struct c_Phone "Phone": > void ring(); > int break(int days); > c_Phone *new_Phone "new Phone" () > void del_Phone "delete" (c_Phone * ptr) > etc.. all classes specified in import list will be imported, also > using of * is > possible. And: > > cdef class Phone import *: > pass > ------------------------- > cdef class Phone: > cdef c_Phone *thisptr > def __cinit__(self): new_Phone() I assume you mean "self. thisptr = new_Phone() > def __dealloc__(self): del_Phone(self.thisptr) > def ring(self): self.thisptr.break() and self.thisptr.ring() > def break(self, days): return self.thisptr.break(days) > > (all like in C++ example on cython.org) > also instead of pass other methods can be specified by hands. Only > specified .h > file and specified class definition parsed, but there is a > possibility to use > 'gcc -E' output (all included) and look at all class hierarchy. Yes, gcc -E would certainly be useful in many cases--we certainly don't want to be doing our own macro expansion and all. > > I used pyparsing module to parse .pyx and .h files. Now tool is in > pre-alpha, > so I have some question: > - how it corellate with Cython developers goals? Does exist a > little chance for > such features to be implemented in original Cython (my project is > only a little > test). The only reason it's not there is because no one's stepped up to do it. Now it looks like you have :). > - is that syntax good ? I like the "cdef extern from 'file.h' import ..." syntax, though perhaps instead of automatically mangling names one should write "import Phone as c_Phone." The "cdef class Phone import *:" seems a bit odd though... A while back we talked about supporting auto- generated methods (e.g. for pickling, comparison, str, ...) and your auto-generated class seems like a candidate for the same syntax. Should "new" and "delete" be added as > - what should I do with arguments of C++ class types? (create > shadows for them!) If we end up creating shadows for everything, then that will slow things down immensely. This is one of the reasons SWIG is slow, and although I think Cython wrappings could be a lot tighter, if we're just passing a bunch of Python objects around there's a limit to how fast you can be. It could be possible to make cpdef functions and only wrap/unwrap things as they pass into Python land (via shadows or ctypes or a CObjects)? Would such shadow types be compatible across modules? > Now TODO list looks like: > - parse C preprocessed files instead of headers (may be done by > pythonic tools > or just 'gcc -E') > - add import lists for extern structs (I not intends to spam local > scope with > identifiers what I've never seen) > - resolve conflicts with already declared names (how?) I think this should just be an error... Eventually, polymorphism would be a very nice thing to have in Cython. > - look through all class tree for public methods and attributes Yep. How to handle class inheritance (and the ensuing type compatibility) is another big question. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
