Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

[Michael D. <md...@st...>]

Including the Cython-generated C in the tarballs and optionally the git 
repository as well can certainly be considered to reduce the need for 
Cython for developers and users alike.  However, the Cython source 
should also be included in the repository for the inevitable times when 
it does need to be updated -- it shouldn't be off somewhere else.

The png, path, ft2font, backend_agg, gtkagg, tkagg, tri, and image 
modules all use CXX.  The backend_agg, image and ft2font ones are 
particularly complex, but some of that complexity could be reduced by 
using Numpy arrays in place of the image buffer types that each of them 
contain (that code predates matplotlib's numpy requirement, so it's not 
terribly surprising that a more complex approach was taken).

Mike

On 12/01/2012 09:44 AM, Michiel de Hoon wrote:
> In my experience, Benjamin is right that the C code is rarely touched. 
> This is even more true for the Python/C glue code, at least from my 
> experience with the Mac OS X backend. Since the Python/C glue code is 
> modified only very rarely, there may not be a  need for regenerating 
> the Python/C glue code by developers or users from a Cython source code.
>
> In addition, it is much easier to maintain the Python/C glue code than 
> to write it from scratch. Once you have the Python/C glue code, it's 
> relatively straightforward to modify it by looking at the existing 
> Python/C glue code.
>
> This argues against making the Cython source code a part of the 
> matplotlib codebase.
>
> At the same time, to minimize errors, we could use Cython to create 
> the initial Python/C glue code, and then add the generated code to the 
> matplotlib codebase. Then neither users nor developers have to install 
> Cython, we don't have to worry about inconsistencies (if any) between 
> different Cython versions, we don't have to worry about keeping the 
> Cython source code and the generated code in sync, and we will still 
> get a high-quality Cython-generated Python/C glue code.
>
> By the way, how many modules in matplotlib make use of CXX, and would 
> have to be converted?
>
> Best,
> -Michiel.
>
> --- On *Fri, 11/30/12, Benjamin Root /<ben...@ou...>/* wrote:
>
>
>     From: Benjamin Root <ben...@ou...>
>     Subject: Re: [matplotlib-devel] Experiments in removing/replacing
>     PyCXX
>     To: "Nathaniel Smith" <nj...@po...>
>     Cc: "Michiel de Hoon" <mjl...@ya...>,
>     "mat...@li..."
>     <mat...@li...>, "Chris Barker - NOAA
>     Federal" <chr...@no...>
>     Date: Friday, November 30, 2012, 8:32 PM
>
>
>
>     On Fri, Nov 30, 2012 at 6:44 PM, Nathaniel Smith <nj...@po...
>     </mc/compose?to=nj...@po...>> wrote:
>
>         On Fri, Nov 30, 2012 at 11:40 PM, Michiel de Hoon
>         <mjl...@ya... </mc/compose?to=mjl...@ya...>> wrote:
>         > 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?
>
>         You can set things up so that end-users don't have to install
>         cython.
>         You just convert the .pyx files to regular .c files before
>         distributing your package. Numpy itself uses cython, but end-users
>         don't notice or care. (It's something more of a hassle for
>         developers
>         to do things this way, and cython is very easy to install, so
>         I don't
>         know if it's worth it. But it's certainly possible.)
>
>
>     Since when has numpy used Cython?  I specifically remember a
>     rather involved discussion thread on numpy-discussion about the
>     pros-and-cons of including cython.  Now, SciPy on the other hand,
>     does utilize Cython in some spots IIRC, but does it in a way that
>     it isn't even required for the developers to have cython installed
>     to build from source.
>
>     I would not be against such an approach.  Much of the C/C++ stuff
>     is rarely touched.  If we have some source cython that is used to
>     generate C/C++ source code that is packaged in the same way as the
>     current code is, I would have no problem with that.  Given that
>     matplotlib is such a fundamental tool in the ecosystem, I want to
>     make sure that the decisions we make are ones that improves our
>     packaging situation.
>
>     Cheers!
>     Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel