One package (Pysam) that I use a lot relies on Cython, and requires users to install Cython before they can install Pysam itself. With Cython, is that always the case? Will all users need to install Cython? Or is it sufficient if only matplotlib developers install Cython?
Best, -Michiel. --- On Fri, 11/30/12, Chris Barker - NOAA Federal <chris.bar...@noaa.gov> wrote: > From: Chris Barker - NOAA Federal <chris.bar...@noaa.gov> > Subject: Re: [matplotlib-devel] Experiments in removing/replacing PyCXX > To: "Michael Droettboom" <md...@stsci.edu> > Cc: "Michiel de Hoon" <mjldeh...@yahoo.com>, > "matplotlib-devel@lists.sourceforge.net" > <matplotlib-devel@lists.sourceforge.net> > Date: Friday, November 30, 2012, 12:32 PM > 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
