matplotlib-devel Mailing List for matplotlib

On 15 March 2013 17:18, Nathaniel Smith <nj...@po...> wrote:
> On 15 Mar 2013 16:50, "Todd" <tod...@gm...> wrote:
> > Within the axes constructor, the constructor would run through each of
> these modules and store them as attributes with the same name as the
> function and the function itself being the contents. At least if me
> understanding is correct, this would make them behave as methods (since
> they are already set up to take an axes instance as their first argument).
>
> This won't work as described - the function -> unbound method -> bound
> method magic only happens for attributes that aren't found in the object
> dict, when lookup falls back on the type dict. You'll want to inject the
> functions into the Axes type object, either via a metaclass constructor or
> just by hand after the type is created.
>
You can manually create bound methods using types.MethodType, if necessary.
However, I think adding them to the class is preferable.
Thomas

On 15 Mar 2013 16:50, "Todd" <tod...@gm...> wrote:
> Within the axes constructor, the constructor would run through each of
these modules and store them as attributes with the same name as the
function and the function itself being the contents. At least if me
understanding is correct, this would make them behave as methods (since
they are already set up to take an axes instance as their first argument).
This won't work as described - the function -> unbound method -> bound
method magic only happens for attributes that aren't found in the object
dict, when lookup falls back on the type dict. You'll want to inject the
functions into the Axes type object, either via a metaclass constructor or
just by hand after the type is created.
-n

On Thu, Mar 14, 2013 at 1:50 AM, Pierre Barbier de Reuille <
pi...@ba...> wrote:
> Hello,
>
> for my own research, I have implemented a function plotting datasets as
> violin plots ( http://en.wikipedia.org/wiki/Violin_plot ). I attach an
> example output that I am using.
>
> It is fairly stand-alone, with the expection of a scipy dependency for
> computation of the estimated density of probability of the shown. Before
> distribution, I will need to document the function and classes associated.
>
> My question is: what is the process if there a place I can make the code
> available for consideration?
>
> Thanks,
>
>
Pierre,
The scipy dependency is unfortunately a deal breaker for matplotlib. I'm
not a core dev, but typically you have a work around the dependency in some
way (e.g., make the user specify the KDE for each dataset).
Also, the statsmodels project has this functionality:
http://statsmodels.sourceforge.net/devel/generated/statsmodels.graphics.boxplots.violinplot.html#statsmodels.graphics.boxplots.violinplot
Perhaps your ideas and approach could be used to improve
their implementation.
-paul

Currently, many of the plot types reside in axes. This makes sense from a
structural standpoint, since the plots are generally a part of an axes.
However, it makes things more difficult from a practical standpoint.
First, it means that the axes class is huge, with both core axes-related
methods and plotting-related methods. Second, it means that boilerplate.py
has to be told explicitly which methods to use, rather than just grabbing
everything from a module. Third, it makes it impossible to break the plot
types into smaller groups of related plots.
The solution, I think, is to move the plots into one or more modules and
implement them as functions. They would have the same call signature as
now, we would just replace "self" with "ax" or something like that. This
would allow you to, theoretically, import and call them without axes, but
this would probably not be common.
Within the axes constructor, the constructor would run through each of
these modules and store them as attributes with the same name as the
function and the function itself being the contents. At least if me
understanding is correct, this would make them behave as methods (since
they are already set up to take an axes instance as their first argument).
The axes would just be left with the methods related to manipulating the
axes themselves.
This would also simplify boilerplate.py, since it would simply need to know
the names of the modules rather than the name of every plot type. It would
then just run through the functions in the modules (or even just run
through all modules in a particular directory). We would probably even be
able to do away with that portion of boilerplate.py completely, creating
the plotting functions in on-the-fly in pyplot at runtime, but that is a
separate issue.
What does everyone think of this approach?