Re: [matplotlib-devel] pyplot-OO convergence

[Nathaniel S. <nj...@po...>]

n Sun, Sep 28, 2014 at 12:40 AM, Eric Firing <ef...@ha...> 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'm not very familiar with matplotlib's guts, but as a user I agree
100%. I'm sure there are Reasons why 90% of pylot functions aren't
simply:

  def foo(*args, **kwargs):
      return gca().foo(*args, **kwargs)

but I have no idea what they are, so whenever I have to memorize two
different APIs for doing the same thing it ends up feeling like a
pointless waste of time.

> 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.

I'd much rather write ax.xlim(...) than ax.xlim = .... The use of that
many magical properties feels unpythonic to me (too much magic!), and
pyplot.xlim() isn't going anywhere. So, it would still mean that
everyone has to learn both the pyplot and the OO APIs separately.
Learning 1 API is always going to be easier than learning two
different APIs, no matter how fancy and polished you make the second
one.

> 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.

In most scene-graphy frameworks, triggering redraws is simply not the
job of the mutator; it's the job of the rendering system to observe
the model for changes. (Using "observe" in the "observer pattern"
sense.) In this approach, every time an artist changes you'd call some
"note_change()" method, which would then propagate upwards. And then
some top-level piece of logic (the canvas or backend, I guess?) would
be responsible for deciding whether it wanted to respond to these
changes. So... very similar to what you're proposing, though with
different terminology :-).

> 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.

Presumably this would be a context manager, 'with artist.hold_changes(): ...'

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org