Looks like a good idea; it allows for a clearer and more logical flow of user code.

This creates the awkward situation that having a gridspec object gs, you don't actually know if you can do gs.subplots() or not. Methods that only work conditionally should be avoided in my eyes.

More generally, I'm still of the opinion that gridspec is a layout submodule and hence should not carry any axes creation stuff inside. The fact that it has a .figure attribute is merely a hack to get constrained layout working.

One main problem I see is that fig.add_gridspec is totally counterintuitive. It doesn't add a gridspec to a figure, no! Instead it adds a figure to a gridspec.

I would be much more inclined to support any solution that allows subplots() to take a GridSpec instance, like

gs = GridSpec(2, 2, width_ratios=[3,1])
fig, axs = plt.subplots(gridspec_kw=gs)

(though of course the _kw part is misleading here, so any alias to ensure backcompat for that would be fine as well.)

Very good points, @ImportanceOfBeingErnest. Maybe plt.subplots(grid=gs). Or even allow it as a sole positional argument, e.g., plt.subplots(gs, sharex=True) etc.?

The name add_gridspec was already bikeshedded in #11010; I do agree it's not great but heh...

If we really want to forget about the fact that gridspecs can be attached to a figure, I would rather spell this functionality gridspec.[add_]subplots(figure=...). Shoehorning this into plt.subplots() just gives us yet another function with an overloaded signature that is a headache to properly document.

More generally, I'm still of the opinion that gridspec is a layout submodule and hence should not carry any axes creation stuff inside. The fact that it has a .figure attribute is merely a hack to get constrained layout working.

Just to push back on this a bit. I consider this a lack in the original hierarchy of organizing elements on a figure. A figure contains a gridspec, and gridpsec "subplots" contain axes or other gridspecs. Without the top-most container, its hard to do layout at the top level.

A gridspec is one of several ways to position axes inside a figure. Axes in a figure can be positionned according to zero or several gridspecs. Also, the same gridspec can be used to position axes in several figures. So, gridspec is not part of any hierarchy.
Since it's also not the only way to position axes (see e.g. the axes_grid toolkit), one should be careful to assume some dependency, which is not reflected in the codebase.
I think it would be nice to keep it as modular as possible to also allow for alternative positionning tools in the future, e.g. https://github.com/matplotlib/grid-strategy

I'm saying gridspecs should be part of a hierarchy, though I agree that is not presently the case. But there is little practical use for them not having a parent container, compared to a huge advantage to being able to state what their parent container is. I think they should do more (i.e. gridspec.suptitle would be very useful and often asked for) and not just be geometric constructions.

In my opinion, grid specs should have a parent. That convenience far outweighs the very mild convenience of being able to treat them as abstract objects that can be shared across figures. Its not exactly hard to write gridspec(a, b) twice, and keep track of a, b instead of the "gridspec".

Not quite sure where this is leading us. Just from the name and original intent GridSpec is just an abstract specification of positions in figure space. Already adding a figure attribute is a deviation from this. Similarly, adding GridSpec.subplots() or GridSpec.parent goes beyond the original intent.

Disclaimer: I don't know in detail how tight_layout or constrained_layout work.

I agree with @jklymak that just an abstract specification is not enough for some use-cases. To a flexible layout mechanism would be need to distribute space to a hierarchy of elements (It's a hierarchy because you have elements that consist of more basic elements; e.g. a figure may contain two Axes, each axes may have ticklabels, maybe an axes-label etc.). The relation between those elements must be specified somehow, and a good established way appear to be Layout elements that are part of the hierarchy. GUI layouts in e.g. Java and Qt work that way and I assume that our layout requirements are not too different from GUIs.

That said, it would be awesome to have such a layout system. But it would need to be designed from scratch. I don't think we can morph GridSpec to such a system.

The other way round, I see the current and proposed extensions of GridSpec as an attempt to realize some capabilities of a more general layout system. But I'm afraid that they cannot live up to their expectations and that we'll end up with a more complex but still only half-baked solution.

Constrained layout works for quite complex layouts just fine with the addition in 2.2 of passing a parent to the gridspec. While I guess if you were to rearchetect it from the beginning you might do it differently I’d be very surprised if you came up with something substantively different than what we have now. I personally don’t think we should let the fact that gridspec started as an abstract thing stop us from making it more concrete. The abstraction is only mildly useful whereas making it an actual container of axes is super useful.

@timhoffm I don't see how this PR is making anything more complicated. It is essentially factoring out the subplots functionality so that it can be used at a lower level.

Pushed an improved version which also supports subgridspecs; see e.g. improvements to demo_subgridspec06 (the improvement would be even clearer if the subaxes needed to be shared).

Did not have time to look into the details here, but I withdraw my original reservation that GridSpec should only be an abstract specification.

I needed this today, and was surprised it wasn't merged! Can this get a second review?

@ImportanceOfBeingErnest, would you like to comment on this? In discussion above and in the meeting, the consensus is moving toward merging this in a week, unless you have objections.

Or gsnew = gs.reuse(newfig)

As discussed in the call, we should have "layout" objects that know about the figure and the relation of its content. That's similar to layouts in GUI (I'm thinking particularly of Qt, but that's what I'm most familiar with). I'm not 100% sure if that's exactly what ConstrainedLayout does.

I'm wondering if we are trying to make GridSpec do too much here. Should we define such layouting concepts from the gound up? If so, it may be that we'd better make a GridLayout and keep GridSpec as an abstract concept instead of having bound and unbound GridSpecs. We would then have something like GridLayout.from_gridspec(gs) instead of gs.reuse(newfig) or similar.

This is clearly not thought out completely, but if we consider going in such a direction, IMHO it would be a mistake to adopt the changes proposed in this PR.

I'm fine if people think we should merge this anyway, but we should be aware what route we are taking here.

Given that you mention Qt: I think Qt actually uses the same classes for bound and unbound layouts? e.g. if you have a QVBoxLayout, you typically want to attach it to a parent (well, call parent.setLayout) before you can do anything useful with it? I also doubt that you can reuse the same layout object on two parents? "The layout will automatically reparent the widgets (using QWidget::setParent())" per https://doc.qt.io/qt-5/layout.html#tips-for-using-layouts.

That's exactly the point. QVBoxLayout is quite unlike GridSpec: It's not an abstract specification but a non-reusable container bound to actual elements. (While you can instantiate a standalone QVBoxLayout, it's only useful when bound to a parent and when you've added widgets to the layout.)

I think we actually need some something like that. And I think it's better to write that from scratch than trying to modify GridSpec into it. As an abstract specification, GridSpec is a separate concept, which can coexist with bound layouts.

What is the practical benefit of an abstract GridSpec versus a bound GridSpec? I appreciate that previously it was abstract, and then I hijacked it to be bound to make constrained_layout work. But that was really the least invasive thing I could do, versus trying to introduce a whole new bound object that did the same thing.

Discussion at the meeting on May 4 suggests that factoring out a gridspec_layout and deprecating the unbound gridspec might be a good move.