[matplotlib-devel] Thoughts on more loosely coupling Axes objects from Figures

[Lee M. <lee...@gm...>]

I'm trying to develop some control-systems libraries and I would like to
add some functionality to give plots of transfer-function representations,
but I've run into a bit of a stumbling-block. For a given transfer
function, I would like to give a way of constructing a an Axes object to be
added into a figure. Normally, it would be just fine to send in an Axes
from the user, but I need a particular (Polar) projection, which can only
be specified at the Axes creation and requires suficient user knowledge to
do something that should be done by the library.

I could not find any way to construct my graph in a function exactly as it
should be represented and then return it for the user to add it into a
figure as a subplot. I could simply be going about this the wrong way, but
I've dug into the sources a bit and I see from the inheritance of the
Artist object that Axes is quite strongly tied into the figure that created
it. It seems that Matplotlib is particularly figure-centric. Now this is
great because it gives you very great tools such as sharex and sharey and
many of the layout options that exist, but for library development, I think
that an axes-centric approach is more useful (so that the user can decide
how to layout multiple graphs representing the library objects, some of
which may need particular labeling and projection settings).

I wanted to see what others thought about this and some options to help
this situation (and to see if others think this is a big issue at all).

Changing Axes itself seems too large a task since it would break API
compatibility, but perhaps there could be ways of importing
already-constructed Axes into a figure. Here are some options:

1) allow the add_subplot and add_axes kwarg 'axes=' to accept any axis,
which it then imports into the figure (possibly creating deep copies of the
Projections and Labels and such)

2) Make new Axes-like (but non-Artist) objects for the user to use (very
similar interface). These would register to figure-aware Axes (possibly
many of them) and propagate plotting function calls down to the Axes. They
would remember the high-level plotting calls that were used on them so that
future registrations of Artist-Axes would reflect everything. this is the
most invasive, yet natural solution to me, but relegates the current
incarnation of Axes into being "back-end" objects.

3) Make Axes its own object and make it use draw calls that take an Artist
to draw high-level plotting functions. This leaves it completely decoupled,
but is likely infeasible.

Please let me know what you think. If there is a clear direction on this,
I'll commit some time to a fix, but I'm not so familiar with the ins and
outs of the code yet.

Lee