Repository navigation
[ENH]: add width/height_ratios to subplots and friends #21942
Description
Currently we must do fig, ax = plt.subplots(1, 2, gridspec_kw={'width_ratios': [2, 1]}). This is pretty clunky, and we now try to shelter the user from the gridspec concept as much as possible. I don't see any reason we should not offer: fig, ax = plt.subplots(1, 2, width_ratios=[2, 1]). See also plt.subplots_mosaic.
I'm not sure about the wspace and hspace parameters. They are somewhat fragile as they get changed by layout managers, but they could also be exposed.
In the case of a clash between width_ratios and gridspec_kw={'width_ratios', []} probably the lower-level call should win.
Marking as Good First Issue, as hoisting this is quite easy, but any new contributors should probably watch this space for an OK as to whether this is generally acceptable.
Activity
timhoffm commented on Dec 14, 2021
I see the basic argument and I'm also sometimes annoyed by the *_kw parameters.
However, I'm concerned that this is an ad-hoc solution addressing a single spontaneous need. The current signature is plt.subplots(..., subplot_kw=None, gridspec_kw=None, **fig_kw). We need to pass subplot, gridspec and figure parameters. If we introduce more top-level parameters, we should look systematically across all parameter. - Maybe even (just an idea, haven't thought this through) we should just fold all parameters in **kwargs and sort them out ourselves.
Also note that the wrapped Figure.subplots() brings along gridspec_kw and subplot_kw. We need to think through whether this is a pyplot-only change or will propagate down.
I'm removing "Good first issue" for now. While implementation is easy, deciding on the API is hard and needs to be done first.
jklymak commented on Dec 14, 2021
We could definitely consider that. I think the only issue is Figure and Axes share quite a few kwargs ('facecolor' comes to
mind) that might make this difficult.
In my experience, however, I don't know that I have ever used sublot_kw. I'd have to look up what those even might be. Whereas I quite often do width_ratios and height_ratios.
I would definitely argue is should be done at the Figure level (and subplots_mosaic as well).
tacaswell commented on Dec 14, 2021
Maybe we can add figure_kw=None to the signature (so the user can always be very specific about which of the places we can route kwargs to) and then start doing the sorting internally?
On one hand, this is a bit hard to explain, but on the other hand it gets us both a) a verbose unambigious way to get the kwargs where they should go b) the nice shortcuts for "do what I mean".
For kwargs that can go to more than one "sink" I can see a case for document the priority order of the sorting and a case for send a copy to everything that can take it.
timhoffm commented on Dec 14, 2021
Ok, checking the support kwargs on the three classes:
Suggestion:
anntzer commented on Jun 23, 2022
FWIW (sorry for being very late to the party) I think that such uses should instead take advantage of GridSpec.subplots() and be spelled
? i.e. it would make more sense if it's subplot_kws that get expanded (although there's admittedly no ambiguity if Figure.subplots also expands width_ratios and height_ratios, so perhaps that's fine too).
jklymak commented on Jun 23, 2022
I think from a user point of view, its a lot nicer not having the intervening layer of API. Now that we have subplot_mosaic, and subfigures, what is the public use of GridSpec that would make us want to encourage exposing it to folks? At this point it feels like it could almost go the other way and become private.
anntzer commented on Jun 23, 2022
Fair point about subplot_mosaic probably taking over most use cases of gridspec from the end-user PoV, I did not think about that.
tacaswell commented on Jun 24, 2022
I am not sold on this statement in general. In this case we are trading some clarity and explicitness for a terser API, which I agree is the right trade off here, it is not cost-free.
I very much disagree with this. Just because subplot-mosaic is taking the 80% case, we should not privatize a more general tool.
jklymak commented on Jun 25, 2022
yes, you are right - subplot_mosaic can nest subfigures for one subplotgrid, but cannot span columns or rows the way it is written now. Though I think it could be changed to handle that. eg.
currently fails, but I think could be made to work by checking for repeat objects in the list, not just repeat strings.