I don't mind this going on the list with the warning that I was not trying to start any sort of anti-SWIG movement -- These are just my first impressions, and at the end of the day I may feel differently. I think you're *dead on* that personal experience and preferences have a lot to do with how these options are evaluated. Although, ideally, it would be nice to find some common ground so we aren't all just hacking on our own things, obviously ;) And it would be nice to find a single tool that is suitable for both C and C++. And it would be nice if it made my dinner ;)
Eric Firing wrote: > 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! My recent fixup was exactly 6 characters -- glad to see they had so much impact! ;) I think the small amount of support is a valid concern, particularly as we move toward Py3k, if no one steps up to the plate to help with the migration. I appreciate the way it fits so nicely into C++ ideas about RAII and exceptions -- but if you're not a C++ guy, that pro is probably a con. > 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. Boost.Python is another option -- probably more like SWIG than pycxx in that the user specifies *how* something should be called rather than the steps to do it. But if you're C++ adverse, that's a huge step in the wrong direction -- it's pretty simple to use when things go well, but when things go wrong, the error messages can be completely inscrutable. ctypes is also an option for calling C code, though I have no experience with it. > 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". Pyrex is "fun to use" and it allows code to be more gradually migrated from Python to C. We would need to take care to not add another run-time dependency for users. (As an aside, I can't find the license of Pyrex. Does anyone know what it is?) > 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. Agreed, it can be tricky to mix C++ exceptions with raw Python/C API wrappers. It's doable by following certain patterns, but it'd be nice to automate those somehow. When I worked on Gamera, there was nothing terribly suitable for the sort of generic programming C++ stuff we had (the kind of C++ that makes you cringe, I'm sure), so we ended up writing our own wrapper mechanism that was very highly specialized. I don't think that approach is necessary or desirable here. I suppose my initial disappointment in SWIG is that I like its fundamental idea -- of automating the tedious boilerplate -- but the execution of it just seems so heavyweight. But maybe that doesn't really matter. This is Python after all ;) Cheers, Mike > 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
