Repository navigation
[ENH]: Support partial figsize setting #31400
Description
Problem
It's sometimes handy to adjust figure height without modifying width. #28758 (comment)
Proposed solution
From #28758 (comment)
Support figure(... ,figsize=...) with tuples where one of x/y can be None with the meaning: Take that component from rcParams["figure.figsize"]; i.e. figsize=(None, 3) is short for figsize=(rcParams["figure.figsize"][0], 3).
Activity
rcomer commented on Mar 26, 2026
If you do
fig.set_size_inches(None, 3)
should the width come from the rcParam or from what was previously set? Or would it not be implemented?
story645 commented on Mar 27, 2026
Since I just saw the figratio pr go by, I think this would be awesome in conjunction w/ a ratio. something like (height, width, ratio) (ETA: which was kinda the original proposal)
timhoffm commented on Mar 28, 2026
@rcomer Set Figure.set_size_inches should not implement not support for None. I don't think there's a natural choice here, so "in the face of ambiguity refuse the temptation to guess".
timhoffm commented on Mar 28, 2026
@story645 you mean something like figsize=(2, None, 3) would resolve to (2, 6)?
I'm not sure this is worth it:
story645 commented on Mar 29, 2026
This would be only used by people who want this functionality? And I don't think it's any more confusing than (2, None) or (None, 2) where I'm left wondering what None resolves to if I don't know he docs.
Sure but the goal is not to have to do the math. Especially if you're messing around a bunch w/ the size and aspect ratio to find what looks good.
If we're internally consistent then at least we're only asking people to work w/ our definition.
jklymak commented on Mar 29, 2026
Nah I think (w, 3*w) is way easier to remember than (w, None, 3) where I also have to remember if 3 is w*3 or w/3. And even if we chose one of these, what would (None, h, 3) mean? Sure you could make rules and have a long docstring to describe it all, or users could do what they currently do which is define a variable and use a tiny bit of elementary math.
story645 commented on Mar 29, 2026
Is more annoying to change if you're messing w/ parameters a lot. And like if you're using (w,h, a) then presumably you know what each parameter does.
timhoffm commented on Mar 29, 2026
figsize=None means "not given; i.e. fall back to the default". Transferring that notion to the individual components seems not too far fetched. The tuple is still only the two components (width, height).
(width, height, aspect) is much more complex: The aspect is a sematically different quantity and pushing it into a plain tuple turns it from a simple size specification (width, height) - possibly with fallbacks to default if not given - to a more complex "set of parameters that define the figure size". What I don't like about this is (i) the lack of names (ii) mixing semantically different quantities (width, height are sizes, aspect is a relation), (iii) the interdependency of the parameters - one size has to be None.
IMHO if you want an aspect, that should go through a function, reviving #21539. I'd be fine with a new figsize() function generalizing on the existing figaspect() so that you can do figsize=figsize(width=10, aspect=2).
I do not follow. The most annoying thing of (10, 10*aspect) compared to (10, None, aspect) (no matter if aspect is a variable or a number) is that you have a duplication and would need to change both. But then again, if you are planning to mess with it, you should likely create a variable width=10 anyway. And then (width, width*aspect) doesn't need to be changed at all.
I want to emphasize that aspect is not a core property of the figure size (as opposed to Axes). The figure size is internally always stored as (width, height). So any aspect handling for the figsize parameter would only be a convenience for calculation during setting.
As stated before, I'm -1 on introducing aspect here because of the obsurity of a (10, None, 2) tuple and because of the inconsistency between our Axes aspect and the general definition of aspect ratio.
jklymak commented on Mar 29, 2026
I'll add that setting aspect will also give the impression we will support that under a GUI dynamic resize (eg you drag a resize corner and the figure changes size but maintains aspect ratio). I don't think we want to do that.
ENH: Support partial figsize with None