Have you considered that people might want suplabels on parts of a grid? e.g. columns 1 and 2 share an xlabel while column 0 has it's own label.

I'm not claiming that you should implement it now or even that it's necessary, but the desire may come up. If we consider this a reasonable extension, we should at least think about if an extension of the proposed API in that direction is possible and staight forward.

Right now the API is the same assuptitle, and that has the same potential to only apply to some axes and not others.

There are two somewhat orthogonal issues here.

1. suplabels don’t align with axes, they align w/ the figure. It’s a reasonable extension to align them with the spines of the child axes, but I’ve not implemented this here. It’s non trivial to do so in a way that works with all the layout managers...
2. How do you only label a subset of axes? I’d argue this is best served with the subpanels/subfigure concept. Then the subpanel gets the suplabels. I think we should make subpanels subclasses of figures (in some way) so they will get this change for free.

i.e. this figure just has suptitles for each subpanel, but was made w two subpanels, and could just as easily have supx and supylabels (from#17437)

Could the functions to add supxlabels and supylabels please be added to future releases of gridspec? Also have multicolumn row titles in the gridspec layout, as in the below figure?

@sks-2020 What do you anticipate wanting to do with gridspec that the sub-panel functionality won't give you?

@jklymak I think the subpanel function will solve what I am hoping to do. My issue is the same as outlined here:
https://stackoverflow.com/questions/40936729/matplotlib-title-spanning-two-or-any-number-of-subplot-columns

I found a possible way of solving this, but doesn't use the neat layout option of using gridspec:
https://stackoverflow.com/questions/27426668/row-titles-for-matplotlib-subplot?rq=1

In summary, I have a gridspec subplots layout within another gridspec. I do the plotting part in the inner grid and need the labeling flexibility in the outer grid. At the moment, using the current release of matplotlib, I can only achieve this using text annotations. Inbuilt functions (like supxlabel, supylabel, supxticklabels, supyticklabels, suptitle), for the outer grid, will be very useful.

@mwaskom This is the suplabel PR. This doesn'treally require the other PR, but would be nice to do it after....

I'm afraid I don't know where to find it in the diff, but is the default font size here bigger than regular axes labels?

I'm not sure I've ever needed to add a "suplabel" pertaining to multiple axes that have existing, distinct labels. My use-case is almost always a situation where I have multiple subplots with shared axes and I want to add a single label to identify them. In that case, I'd want to the label to have the same size as a normal axis label.

Also, will these suplabels be tighter against the axes when there are no first-order labels?

I won't assert or claim to know which is a more common usecase, but I do think it's an application this PR should consider...

I think they may be larger by default (just like suptitle) but the user can change this.

If there are no individual labels and you use constrained_layout the suplabels will be tight against the axes. Can likely be made to work with tight_layout as well. With no layout manager the whole thing is a bit of a mess anyhow.

As noted above, the suplables will be centered on the figure, not the spines or some other measure of what the label is supposed to span. That may or may not be acceptable depending on axes decorations, but it's a lot simpler.

This is ready for review, and closes at least one feature request, and something seaborn would like.

Were we relying on Travis to run any unique test configurations? I'm wondering why test lines execute has dropped so much...

Is it not posting? It seems to have run...

Not everything is installed in Azure Pipelines, so I don't think it covers the same things.

Travis CI doesn't show up in the current list of checks on this PR. It looks like no PR builds have run in 3 days. I'm assuming we're running into the same thing that SciPy and NumPy have run into due to Travis changing their pricing model:

Oh, I did not notice the date. I guess we'll put this back on the meeting agenda.

Anyone can merge on CI green.

Code coverage is normal again, since this ran with GitHub Actions after@tacaswell's commit.

Thanks for everyone's reviews, and for@QuLogic for fixing codecov!