[ENH]: Support partial figsize setting

[timhoffm]

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).

[rcomer]

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]

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]

@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]

@story645 you mean something like figsize=(2, None, 3) would resolve to (2, 6)?

I'm not sure this is worth it:

• (2, None, 3) is hard to read.
• (width, 3*width) - or (2, 3*2) is not too hard to write.
• Our aspect definition (Axes.set_aspect) is y/x whereas the typic aspect ratio definition is width/height https://en.wikipedia.org/wiki/Aspect_ratio_(image). So when introducing the aspect concept here we are either internally consistent or consistent with public image conventions - either gives rise to confusion. Avvoiding aspect may be the better option.

[story645]

(2, None, 3) is hard to read.

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.

(width, 3width) - or (2, 32) is not too hard to write.

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.

Our aspect definition (Axes.set_aspect) is y/x whereas the typic aspect ratio definition is width/height

If we're internally consistent then at least we're only asking people to work w/ our definition.

[jklymak]

Nah I think (w, 3w) is way easier to remember than (w, None, 3) where I also have to remember if 3 is w3 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]

is way easier to remember

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]

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.

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).

---

Is more annoying to change if you're messing w/ parameters a lot.

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.