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