Just for completeness, there is also ctypes. I wrapped the freetype library (http://code.google.com/p/freetype-py/) using it and it is quite easy (and boring). But this only works for C (not C++).
Nicolas On Dec 6, 2012, at 18:06 , Michael Droettboom wrote: > I think this has been a very helpful and useful discussion. > > I'm going to attempt to summarize this discussion and propose some ways > forward here. > > The impetus for this discussion is that PyCXX seems to be not adequately > maintained. It is difficult to build matplotlib with "vanilla" PyCXX in > certain configurations. (This history sort of predates this thread). > > So we have some options: > > 1) One way forward is to offer to take ownership of the PyCXX project. > (I'm not using the "f" word here... I'd much prefer to just become more > involved upstream somehow). I don't think this would be considerable > additional work, as most of that work has been done in matplotlib for > some time anyway. To the extent that it needs new features, it would be > killer to add support for Numpy so Numpy no longer required manual > reference counting. I had initially dismissed this approach, as I seem > to be in the minority in liking PyCXX -- I happen to think it's > fundamentally an extremely good approach to the problem: it helps with > reference counting errors, but otherwise mostly stays out of the way. > But I'd like to remove any one person as a bottleneck by choosing > something that's more preferred all around. > > 2) Move to a different wrapping mechanism of some sort. While Cython is > the clear choice for a third-party Python/C wrapping tool, it seems to > be polarizing. (I won't attempt to repeat or summarize, but I think > good points have been made on either side of the argument). I think > it's ok to allow Cython to be used in matplotlib, given that we include > both the Cython source and the generated C in the source repository such > that matplotlib can be built without Cython installed. There are many > other projects doing this that can provide best practices for us. I > don't think, however, that we can or should require that all wrapping is > done with Cython. I think we should allow raw Python/C API where it is > most appropriate (and that is mainly in the case of wrapping third-party > libraries, such as the png module and the macosx module which is already > raw Python/C API). What I wouldn't want to see is the use of more than > one wrapping tool, if only for reasons of proliferation of > dependencies. (I count the Python/C API as "free" since it's always > available anyway). I haven't seen in this discussion anyone really > pushing for any of the alternatives (SWIG, Boost.Python, etc.) in any event. > > Note also, the goal is to deal with the PyCXX "problem", not rewrite > large chunks of our existing and well-tested C/C++ code base in Cython, > unless someone sees a real clear benefit to doing that for a particular > module and is highly motivated to do the work. This is primarily about > refactoring the code so that the interface layer between Python and C is > separated and then replaced with either Cython or raw Python/C API using > the most appropriate tool for the job. > > 3) Any other options...? > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
