Repository navigation
FR: Figure.subplots add optional SubplotSpec parameter #11288
Description
Figure.subplots is a convenient method for creating a grid of subplots with shared axes, with the redundant tick labels and such automatically handled for you. It would be helpful if this method could also be used to help create more complicated layouts, such as ones with a few independent sets of shared axes that you would create with several calls to gridspec.GridSpecFromSubplotSpec.
For example:
import matplotlib.pyplot as plt
import matplotlib.gridspec as gridspec
import numpy as np
fig = plt.figure()
gs = gridspec.GridSpec(1,2)
####
# The following block could be replaced by this proposed function call:
#fig.subplots(nrows=2, ncols=2, subplotspec=gs[0], sharex='col', sharey='all',
# squeeze=False, gridspec_kw=dict(hspace=0.07))
gs0 = gridspec.GridSpecFromSubplotSpec(2, 2, gs[0], hspace=0.07)
ax0_00 = fig.add_subplot(gs0[0,0])
ax0_01 = fig.add_subplot(gs0[0,1], sharey=ax0_00)
ax0_10 = fig.add_subplot(gs0[1,0], sharex=ax0_00, sharey=ax0_00)
ax0_11 = fig.add_subplot(gs0[1,1], sharex=ax0_00, sharey=ax0_00)
ax0s = np.array([[ax0_00, ax0_01], [ax0_10, ax0_11]])
for ax in ax0s[:-1].flatten():
ax.tick_params(axis='x', which='both', labelbottom=False)
for ax in ax0s[:,1:].flatten():
ax.tick_params(axis='y', which='both', labelleft=False)
####
####
# The following block could be replaced by this proposed function call:
#fig.subplots(nrows=3, ncols=1, subplotspec=gs[1], sharex='all', sharey='all',
# squeeze=False, gridspec_kw=dict(hspace=0.1))
gs1 = gridspec.GridSpecFromSubplotSpec(3, 1, gs[1], hspace=0.1)
ax10 = fig.add_subplot(gs1[0])
ax11 = fig.add_subplot(gs1[1], sharex=ax10, sharey=ax10)
ax12 = fig.add_subplot(gs1[2], sharex=ax10, sharey=ax10)
ax1s = np.array([[ax10], [ax11], [ax12]])
for ax in ax1s[:-1].flatten():
ax.tick_params(axis='x', which='both', labelbottom=False)
for ax in ax1s[:,1:].flatten():
ax.tick_params(axis='y', which='both', labelleft=False)
####
fig.tight_layout()
plt.show()
Adding a subplotspec optional argument to Figure.subplots, which when supplied would call gridspec.GridSpecFromSubplotSpec (with the provided SubplotSpec) instead of gridspec.GridSpec, would be all that is required.
The exception to this is for constrained layouts, which I'm not familiar with. gridspec.GridSpecFromSubplotSpec doesn't accept a figure parameter, but seems to inherit that information from the SubplotSpec, and so would rely on passing the figure to the "parent" GridSpec in the first place?
Activity
jklymak commentedon May 23, 2018
I think something like this can/would be useful. I think its exactly what I am proposing in #11010 except I'm not proposing a kwarg to
figure.subplots, which maybe is a good idea, maybe is a little too crufty...attoblarg commentedon May 23, 2018
I think what I'm requesting be added is independent of #11010. My request is not about creating/managing GridSpec and related objects, but about being able to use the conveniences provided by
Figure.subplots(automatic managing or shared axes setup and display) for multiple independent times in smaller subsections of the same figure (usinggridspec.GridSpecFromSubplotSpec).I believe this would be an easy pull request except that I'm not sure how to handle the constrained layout case if the passed SubplotSpec argument was not setup to use a constrained layout. I am hoping for advice/recommendations on this point.
jklymak commentedon May 23, 2018
I agree this is a bit different from #11010, but I don't want it to be independent. I don't think that
figureis the correct class for this. I'm trying to get us thinking about these layouts more heirarchically, and I'd prefer this be a method onSubplotSpec, so you'd callinstead of adding a kwarg to the figure method...
In either case, so long as you use
SubplotSpecthis should all work fine w/constrained_layout. The only thing in the code above that you need to change is to do:(i've also proposed adding
gs = figure.GridSpec(1, 2)in #11010 to get arpund the akward passing of the figure kwarg)I'm not vetoing making this part of the
figure.subplotapi, but it would make organization of the plotting hierarchy clearer to have the public API be that this is a method ofSuplotSpec. One may implement it as a private kwarg tofigure.subplotsif that is more convenient...attoblarg commentedon May 23, 2018
I understand now what you meant, and I agree that, in your proposed changes, a call like
is exactly what I'm requesting. However, even if what you are proposing is accepted, I think adding this to
figure.subplotsis still helpful, unless it would be deprecated.jklymak commentedon Sep 26, 2018
I'm going to close this as covered by the merged #11010. If those additions are not adequte we can re-open discussion....