Summary

Split out of#24617. Before we can implement this, we need a though API discussion (#24617 (comment)).

Current state:

• The kwargfigsize is IMHO well named and extremly widely used. It must stay as is.
• The methodsset/get_size_inches() as also widely used (90k matches on GitHub) and thus cannot be changed

We have to make a tradeoff decsion here: What is worse the naming inconsisteny (1) or multiple functions doing the same thing (2)?

I'm ok with going with (2), under the condition thatset_figsize() andset_size_inches() as not equal aliases. There should be a clear guidance what to use. In practice that means discouragingset_size_inches in favor ofset_figsize().

There's a separate discussion whetherset_figsize() should accept both two individual parameters as well as one tuple. The tuple is mainly to makefig.set(figsize=(w, h)) work because that single tuple is forwarded toset_figsize, but we could also create API infrastructure that specifies on the setter how multipe parameters can be handled in a set() call, i.e. there would be an internal preprocessing that unpacks the tuple for theset_figsize call.

Side-note: I've recently created#29612 to (partially) address the long-standing and much asked-for figure unit topic. One could expand that toset_figsize() later.

Discarded: When moving API anyway, one could consider going withsize instead offigsize. That's shorter andfig.set_size() /plt.figure(size=...) would work well. However, it would be an even larger API break, and we cannot use that forplt.subplots(..., size=...), because that would be too ambigous. Thereforesubplots(..., figsize=...) must be kept. While we strictly don't need to have naming equivalence betweensubplots() andfigure concerning this parameter, overall it's not worth it, so let's stick tofigsize everywhere.