Repository navigation
plt.subplots for already existing Figure #5139
Description
The plt.subplots function in very practical for creating a large number of axes simultaneously, but (afaict) always puts them on a new figure, which is impractical e.g. when embedding matplotlib in a GUI, where a Figure object may be created early on and then populated with some axes later.
I would thus suggest providing the same functionality to already existing Figure objects, e.g. by moving the implementation of plt.subplots to a Figure.add_subplots (or Figure.set_subplots, as it may make sense to clear the figure before) method, and have the plt.subplots function be a thin wrapper that creates the Figure and then calls its add_subplots method.
Activity
tacaswell commentedon Sep 25, 2015
You can use gridspec + a for loop to do this.
WeatherGod commentedon Sep 25, 2015
I can see the point in this, but I feel that it goes against what we have
been trying to do, which is to decouple pyplot from the OO interface.
On Fri, Sep 25, 2015 at 8:47 AM, Thomas A Caswell notifications@github.com
wrote:
anntzer commentedon Sep 25, 2015
I know about GridSpec, it is just a bit awkward to use especially when you also want to use share{x,y}.
efiring commentedon Sep 25, 2015
Actually, moving the
subplotsfunctionality for generating a whole array in one whack into Figure is a step towards decoupling pyplot from the OO interface.tacaswell commentedon Sep 25, 2015
On consideration, I now agree this is a good idea. This should be a pretty strait forward copy-paste job, @anntzer want to take a crack at it?
Move impl. of plt.subplots to Figure.add_subplots.
anntzer commentedon Sep 26, 2015
I intended to name the new method
Figure.add_subplots(by similarity withFigure.add_subplot) but @tacaswell prefers to keep itFigure.subplots(by similarity withplt.subplots). Any thoughts?efiring commentedon Sep 26, 2015
I can see arguments either way, but overall I agree with @tacaswell. It's shorter. Also, unlike
add_subplot,subplotsnormally would be called only once for a given figure, unless it is cleared.anntzer commentedon Sep 27, 2015
Sure, I'll change that. The other question was whether
Figure.subplotsshould callclffirst. @tacaswell suggested yes, but I'd rather not because (copy-pasting from diff discussion) IMO if you use the OO interface you know what you're doing and it's anyways easier for the caller to add a call to clf rather than to remove a call to clf if it's already there.efiring commentedon Sep 27, 2015
I don't know. @tacaswell, if
clfis called inside, should observers be kept, or not? The danger of not includingclfis that people might callsubplotsrepeatedly on the same figure until they run out of memory, or something else goes haywire.tacaswell commentedon Sep 27, 2015
My main reason for wanting to call
clfis that I don't like the logic that will, if things line up just right,add_subplotwill return back to you a reference to an existing instance, but sometimes gives you back overlapping plots.On the other hand, the reason to not call
clfis to add a bounding box input toFigure.subplots(which iirc can go in through thegridspec_kw?)efiring commentedon Sep 27, 2015
On 2015/09/26 3:56 PM, Thomas A Caswell wrote:
This is a real mis-feature. We need to get rid of it ASAP, which
unfortunately can't be all that soon.
tacaswell commentedon Sep 27, 2015
it also turns out that it (for what ever reason) does not do that in this case and just keeps layering new axes on.
chanansh commentedon Jan 16, 2017
Was this added to the package?
tacaswell commentedon Jan 16, 2017
Yes, but it is currently on the master branch and not in a released version of the library.