Mike, I hope you don't mind my including the devel list on this; I think it is a very important topic (although it may be one that ends up coming down to each individual's personal experience and preferences).
The reasons pycxx worries me are: 0) C++ worries me in general--I know lots of wonderful code like Agg is written in C++, but personally I find C++ hard to deal with. This is mainly my problem. (But maybe not entirely. From the SWIG history: "February 11, 2000. SWIG1.3 alpha released. This is the first in a series of releases that slowly migrate most of SWIG's implementation back to ANSI C.") 1) Transform module classes wrapped with pycxx have some strange characteristics, and don't behave like nice python classes. Sorry this is vague, but I stumbled on it, and John confirmed it, months ago, and then I blissfully forgot all the details. I can probably dredge them up from the mailing list if it would be of interest. 2) Given my discomfort with C++, I am even more uncomfortable relying on what seems to be an almost unmaintained component. All the warnings were worrying me, for example. Your recent fixups have reduced that source of discomfort! Swig: I agree with you on that one. I have never taken to swig either, although I recognize that it has many fans. I'm afraid that it may be the only automated game in town for C++ apart from PyCxx, though. GvR's comments are interesting. Pyrex: now, there is something I like! Not so great for C++, but it surely is nice for wrapping C, and for speeding some things up while writing "almost Python". Native API: I've done a little of that--the cntr.c interface code. The good things are that it eliminates another layer of dependency, and what you see is what you get. It is pretty tedious, though, and there are lots of gotchas. For me it is a reasonable choice for C code, although I would still gravitate towards Pyrex in most cases. For C++, I would not know where to start. Again, that's my personal handicap. Eric Michael Droettboom wrote: > Eric Firing wrote: >> Mike, >> >> Thanks for fixing pycxx to remove all those warnings! >> >> I am curious: have you looked at the most recent upstream pycxx? My >> impression is that there were supposedly some changes to support >> python 2.5, and a couple months ago I made a feeble and unsuccessful >> attempt to use the updated version in place of the one included in mpl. > > I looked at it a while ago because I suspected it might be the cause of > a segfault. (Turned out it wasn't). I diffed it against the mpl one > and didn't see much of significance, but I was really only looking for > potential memory usage mistakes. > > It looks as if some Python2.5 changes have already been made in mpl. All > the references to Py_ssize_t are a Python2.5-ism, for instance. > >> In any case, perhaps your improvements can be incorporated upstream. > > It actually looks like someone else has already arrived at the identical > fix! > >> Longer term, I will be pleased if our dependence on pycxx can be removed. > > It's funny you bring this up. I know that's on John's wish list. I > just spent a little time looking at SWIG (trying to convert my simple > ttconv extension to use SWIG), and I have some real concerns about it. > > For one, the syntax is weird, and it seems like any real-world > non-trivial extension requires all kinds of magic goo. > > Secondly, it generates very bloated and suboptimal wrapper code, even > after experimenting with the myriad of options to cut down on what gets > generated. With my ttconv extension the object file doubled in size, > since it appears to be throwing in all kinds of stuff we don't need. > > GvR said: > > "I've yet to see an extension module using SWIG that doesn't make me > think it was a mistake to use SWIG instead of manually written wrappers. > The extra time paid upfront to create hand-crafted wrappers is gained > back hundredfold by time saved debugging the SWIG-generated code later." > > http://www.artima.com/weblogs/viewpost.jsp?thread=95863 > > In my own experience, writing to the Python/C API directly is not > horrible, but there are lots of pits to fall down if you're not careful. > GvR wrote a lot of that API, so I'm not sure I agree with the full > strength of his statement ;) > > However, SWIG rubs me the wrong way, including its history of needing a > specific version to get a specific result. (I don't know if they're > still breaking backward compatibility at the same rate that they once > were.) > > I would hate to move away from CXX because it is less popular (unless > the lower popularity translates into a real loss of utility, like > updates following Python releases). There are a lot of things in this > world that less popular but still superior -- think of beers for > instance ;) I would just advocate looking at all the alternatives to > SWIG, including raw Python/C API. > > (Again, I'm late to the party, so forgive me if my assumptions are wrong > or these things have already been worked through.) > > Cheers, > Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
