I am against pushing the pyplot style title/xlabel/.. function down
into the OO layer, I really do not like the different behaviour and
returns depending on the arguments. That has always struck me as a
MATLAB-ism that should be dropped, but we are stuck with to maintain
back-compatibility.
I have been thinking about going a very different route and pulling
almost all of the plotting function _off_ of the axes objects and just
having functions with signatures like
def plotter_function(ax, data1, data2, style1, style2,...)
art = create_artists(...)
ax.add_artists(art)
return art_list
And then almost all of pyplot can be replaced with a wrapper function:
def wrap_for_pyplot(func):
def inner(*args, **kwargs)
ax = plt.gca()
art_list = func(ax, *args, **kwargs)
if plt.is_interactive():
ax.figure.canvas.draw()
inner.__name__ = func.__name__
inner.__doc__ = strip_ax_arg(func.__doc__)
return inner
for f in funcs_to_wrap:
pyplot.setattr(f.__name__, wrap_for_pyplot(f))
Which pushes all of the interactive/global state related stuff up to
one place and removes the need for keywords to suppress re-drawing/the
need to manage that. This will make embedding a lot easier as well.
I have also been thinking quite a bit about the semantic
artist/manager layer of objects which I think would also go a long way
making the library easier to use, but that is a different story.
Tom
On Sat, Sep 27, 2014 at 7:40 PM, Eric Firing <efir...@hawaii.edu> wrote:
> One of the biggest causes of controversy in mpl, and of difficulty in
> teaching and learning mpl, is the divide between pyplot and the rest of
> the library. There are at least two aspects:
>
> 1) plt.title() versus ax.set_title(), etc; that is, all the clunky
> getters and setters on the OO side. JDH used to note that they were a
> side-effect of his C++ heritage, and that he probably wouldn't have used
> them if he had had more Python experience when he started mpl.
>
> 2) For interactive use, such as in the ipython console, one really wants
> pyplot's draw_if_interactive() functionality; one doesn't want to have
> to type explicit plt.draw() commands. Worse, plt.draw() operates on the
> current figure, which might not be the figure that one just updated with
> "ax2.set_title('the other plot')".
>
> I think that both of these speed bumps can be removed fairly easily, in
> an entirely backwards-compatible way.
>
> The first is just a matter of propagating some shorter-form pyplot
> function names back to Axes and Figure. This idea is mentioned at the
> end of MEP 13, as an alternative to properties.
>
> The second requires accepting some behavior in the Axes and Figure
> classes that is conditional on the backend and the interactive state. I
> think it would look *roughly* like this:
>
> Add a method to Figure:
>
> def draw_if_interactive():
> if not is_interactive:
> return
> if not isinstance(self.canvas, interactive_canvases):
> return
> self.canvas.draw()
>
> Append this method to suitable Figure methods such as suptitle().
>
> Add a method to Axes:
>
> def draw_if_interactive():
> self.figure.draw_if_interactive()
>
> Append this method to suitable Axes methods--all those that execute
> changes, or at least those with corresponding pyplot functions.
>
> Some additional logic (either a kwarg, or temporary manipulation of the
> "interactive" flag, or of an Axes instance flag) would be needed to
> block the drawing at intermediate stages--e.g., when boxplot is drawing
> all its bits and pieces.
>
> After these changes, the pyplot functions could be simplified; they
> would not need their own draw_if_interactive calls.
>
> Am I missing some major impediment? If not, I think this set of changes
> would make it much easier to use and teach the OO interface, with pyplot
> still being used where it is most helpful, such as in the subplots() call.
>
> Eric
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Thomas Caswell
tcasw...@gmail.com
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
