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.r...@ou.edu>/* wrote:
From: Benjamin Root <ben.r...@ou.edu>
Subject: Re: [matplotlib-devel] Experiments in removing/replacing
PyCXX
To: "Nathaniel Smith" <n...@pobox.com>
Cc: "Michiel de Hoon" <mjldeh...@yahoo.com>,
"matplotlib-devel@lists.sourceforge.net"
<matplotlib-devel@lists.sourceforge.net>, "Chris Barker - NOAA
Federal" <chris.bar...@noaa.gov>
Date: Friday, November 30, 2012, 8:32 PM
On Fri, Nov 30, 2012 at 6:44 PM, Nathaniel Smith <n...@pobox.com
</mc/compose?to=n...@pobox.com>> wrote:
On Fri, Nov 30, 2012 at 11:40 PM, Michiel de Hoon
<mjldeh...@yahoo.com </mc/compose?to=mjldeh...@yahoo.com>> 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
