On Fri, Nov 30, 2012 at 6:06 AM, Michael Droettboom <md...@stsci.edu> wrote:
> If you read between the lines of what I was saying, that is basically > where I fall as well. There seems to be a lot of desire to use Cython > to make the code more accessible, I'll add a beat to that drum -- I'm a big Cython fan. > however, and I'm willing to consider > it if it can be shown to be superior to the raw C/API for this task -- I think there is NO QUESTION that Cython is superior to the C/API -- why would you want to deal with the reference counting, etc yourself? Cython can handle the boiler plate code for you very cleanly an elegantly. Something to keep in mind about Cython: It can be used in multiple ways: 1) Add static typing to what is essentially Python code to get better performance -- this may be what you mean by the "more accesible" part. A great use, but maybe, maybe, maybe not best for the core bits of MPL. 2) Calling C/C++ code -- Cython is s great way to call C/C++ code -- it can handle the packing and unpacking of python types, reference counting, etc. for you, so much like using the C API, but a lot less tricky boiler plate code to write. (2) is the use case that I'm arguing is NO QUESTION a better option than the C API. Compared to SWIG, SIP (and I assume C_XX), the downside is that there is no auto-generation of wrappers (at least nothing mature). However, for the MPL case, we're not trying to wrap a large existing library, but rather particular code that is often written for MPL specifically, so hand-writing the Cython is a fine option. So why not Ctypes, or??? I think the real strength of Cython in wrapping C code is that you can write a "thick" wrapper in an almost_python language. So if you want to vectorize a C function, for instance, you can write that bit in Cython very easily (and Cython's built-in understanding of numpy array is very helpful here). When you use ctypes, you need to write that in pure Python -- easy enough, but probably not very performant. With SWIG, etc, you end up writing a fair bi tof C (or SWIG) code to handle the thicker bits of the wrapper -- so you're dealing with the raw CPython API, and , well, C. Cython really is an easier option. I've found that for stuf that is less than very small (i.e. one or two loops through an array), writing the core code in native C or C++ can be easier, you know for sure you're not accidentally making expensive Python calls, etc. but using Cython to call it is still very helpful. > I'm not sure it is -- I always seem to end up with things that are more > lines of code with more obscure workarounds than just coding in C directly. Exactly -- but I don't think that applies to the CPython-API bits, but rather the core code -- so keep that in C. In summary, I guess what I think is the power of Cython is the flexibility in where you draw the line between Python, Cython, and C -- you can pass pure Python through Cython, or you can do almost nothing with it but call a C function, and eveything in between. > From my experience, I would prefer to write such extensions in C directly > rather > than relying on Cython, SWIG, or Boost.Python, because those approaches would > lead to another dependency (for developers at least), The dependency is pretty easy to deal with compared to the many others in MPL. > and requires developers to > learn how to code in them. Which may not be very hard, but we may as well > avoid > that if possible. Here's where I disagree -- if we go pure C and C-API developers need to know the Python C-API -- that is actually a pretty big deal, and hard to get right. Knowing enough Cython to call some C code is a smaller lift for sure. Anyway, I saw give it a shot -- I suspect you'll like it. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
