Robert Bradshaw <[EMAIL PROTECTED]> writes: > > > > I think a) has a very wide circle of potential users, and perhaps > > getting this integrated first could be a first goal here? > > Yes, for sure. I've actually thought about doing this several times, > but there have been too many other things higher on my list. >
Hmm.. almost all users of SWIG just sleep and dream how to get it work faster. But they are lazy and cython has no autogeneration... > > As for syntax, here's another idea (not that I'm against the > > original proposal): > > > > For a): > > > > from "myheader.h" cimport foo > > I like this syntax. Yeap, it looks much nicer than "cdef extern from.." - horrible bunch of Pyrex, C and Python keywords. > However, it seems like the intent is to make easy shadow classes, and > for this purpose it could serve very well. Should all the methods be > exposed? (One would certainly want to have that as an option.) If > not, how to select them? This is why I started to use "cdef class Foo import *:" - list of exposed methods can be just specified like import list. "cdef class Foo import add, sub, mul, div:". Fake "inheritance" may only replace common * variant where all public methods exposed. > > > Finally, thoughts on integration with Cython: The first thing to do > > after a successful integration of what exists now, would be looking > > at producing a "tree preprocessor" rather than file preprocessor. > > I.e. in whatever code exists now it should be rather simple to emit > > the nodes of Nodes.py rather than Cython code strings, which should > > give a performance boost and make things less complex overall. > > Yep, though the main work is that one doesn't start with at tree > (especially for (a)). Also, decelerator nodes are such a pain to > produce. But this is not justification to not do it the right way. > It'd be awesome to have something that takes a .h file and produces a > parsed pxd tree. What pxd you mean ? Generated with regard to classes specified in "..extern.." statements or entire .h converted to pxd? > > > As for pyparsing, I note my disagreement with Robert. I don't think > > it would hurt to add another dependency as long as it is an > > optional for optional features, at least if switching parser is > > nontrivial. > > I don't see this as an "optional" feature, but something we should > have in the core of Cython. We already ship with a parser, so if > possible I'd like to use that one. > > - Robert > This is realy not a great point, what parser to use, because I've written very raw program and used most simply tool. Let teach PLEX to handle .h and use it. I've tried not to interfere in cython code at start. _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
