On Oct 19, 2008, at 1:10 PM, Dag Sverre Seljebotn wrote: > Some random thoughts on this: > > This is basically two orthogonal things (as given in two seperaate > examples): > a) Automatic inclusion of .h-files "as if they were pxd files" (or, > making pxds unecessary). This has very wide uses. > > b) Automatic generation of wrappers for cpp classes. > > 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. > 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. > > (or from cython.cheaders.myheader, or similar) > > I.e. the .h-file acts exactly like a pxd file. This should > integrate very nicely with existing codebases (i.e. some pxds could > simply be deleted and the import changed and things would still > work the same :-) ). > > This has some problems with performance obviously - only the > necesarry symbols should go from .h to "implicit pxd" stage. It > looks like this is in place though from the other syntax, and now > that type symbol resolution is postponed to after parsing (yey!) > this could even work with a normal "cimport 'myheader.h' as mylib; > mylib.foo(...)"... For both .pxd and (eventually) .h, I think caching will greatly mitigate these performance issues. If .h parsing is considerably slower though, it might be useful to have a .h -> .pxd utility. > For b), I'm thinking something like: > > from "mylib.h" cimport MyCppClass > > cdef class MyCyClass(MyCppClass): > pass > > i.e. you can "inherit" from the C++ class in Cython. This also > provides a nice syntax right away for extending the wrapper with > more stuff in addition to the automatic part. I thought of this too. It's nice syntactic sugar, but it's a bit odd in the sense that now MyCyClass can't inherit from something else (well, I suppose we could do multiple-inheritance syntax) and we might want to expose the inheritance tree of MyCppClass somehow as well. 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? > 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. > 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 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
