This has come up before and I am still not convinced this is a good idea (but am more convinced than I used to be).

Any other opinions one way or another for this? I'll give it +1 because I don't think its too crufty, and its backcompatble.@tacaswell seems -0.5?

• I find it ok to be able to specify the size in different units, but still do all the internal handling and the returned size in inches. This is just a convenience converter for the inputs. No need to make all the internal logic and getters unit-aware. After all, setting the size is much more common than querying the size.

• Personally, I don't useFigure.set_size_inches but only thefigsize kwarg. Since this is all about convenience, I'm afraid just addingFigure.set_size will not reach the goal unless we're going to makefigsize accept units as well.

  fig, ax = plt.subplots(figsize=(8/2.54, 6/2.54))

  is still more convenient than

  fig, ax = plt.subplots()fig.set_size(8, 6, unit='cm')

• We should not haveFigure.set_size andFigure.set_size_inches as equal options. The should be only one way, meaning we would have to deprecateFigure.set_size_inches.

• I'm a bit worried about the permitted values.set_size(8, 6, unit='cm') seems perfectly reasonable.set_size('8cm', '6cm') is a bit more unconventional. If it was just aboutset_size, I wouldn't allow string values. However, that poses the question onplt.subplots(figsize=). Here you would either haveplt.subplots(figsize=('8cm', '6cm')) or you would need a separate kwargplt.subplots(figsize=(8, 6), figunit='cm'). I'm -0.5 on string arguments and -0.8 on extra figure keywords.

  Another alternative would beplt.subplots(figsize=(8, 6, 'cm')), which is not great, but IMHO the best compromise to specify units. Getting a good interface forFigure() andsubplots() is the crucial point to me. Otherwise, unit support does not have a real benefit.

To sum up, my recommendation is:

• Figure.set_size(width : float, height : float, unit='inch', ...)
• deprecateFigure.set_size_inches
• acceptFigure(figsize=(8, 6, 'cm'))

Please don't deprecateFigure.set_size_inches. The number of people who will then need to change their code is certainly higher than the number of people who benefit from introducing the metric stuff.
So from my side -10 on deprecating anything here, ±0 on adding functionality.

@ImportanceOfBeingErnest I see your point. OTOH two functions are clutter in the long run. Maybe just add a note to the docstring thatset_size() is preferred overset_size_inches() - similar to how we don't deprecate pylab. And maybe maybe deprecated in 4.0?

@timhoffm I agree - we need something for thefigsize kwarg. This change accepts three-tuple or two-tuple of strings (as well as keeping old behaviour)

@jklymak Basically, +1 for supporting the three-tuple figsize. However, I'm still -0.5 on string values.

Both APIs need to be discussed with other devs. It's likely that there will still be changes. You might want to wait with the actual implementation until the API is finally decided upon. Otherwise, you may have duplicate coding work. Just saying. Of course you are free to update proof-of-concept code as we discuss 😄 .

I agree with most of what@timhoffm and@ImportanceOfBeingErnest said (which are the reasons I am not convinced on this).

Balancing {"passing non-inch values toset_size_inches", "we don't want to have two functions that do the same things", "we can not deprecatedset_size_inches} has been the sticking point on this before.

I like@timhoffm 's suggestion of letting thefigsize kwarg take a triple, a pair of inches, or a pair of strings maybe the best path forward (and leavingset_size_inches alone). It extends the API in a pretty natural way, is back compatible, adds no new names, and does not have any weird name / input clashes.

@tacaswell actually, I'm not advocating the "pair of strings" option. I find that a bit unconventional. And it's basically redundant (=not needed) if we have the (width, height, unit) triple.

I thinkfigsize=(x, y, "cm") looks ok ((x, y, "px") may be nice to have too).
I'd still introduceset_size and "deprecate-in-docs" (à la pylab)set_size_inches but that's a separate point. (But of course then the question is whetherset_size(x, y) should work with the meaning ofset_size(x, y, "in")... I guess we can always postpone this question to later :))

My vote would be for default inches as the float-only API. Historically it’s what we have offered, internally it’s what we use, and I’mnot in favour of some sort of unitized getter for figure size. Anyone who needs to programmatically get the size of a figure is surely capable of converting in their code. Thus allowing inches only as the default is good because it lets the user know that’s our default and internal convention. The units are just there as a mild convenience.

px now works (if dpi is set):

fig,ax=plt.subplots(figsize=(500,300,'px'))

OK, thanks for everyone's work on this. In the spirit of keeping things simple, I think folks will have to make due with converting in their downstream code. If anyone wants to take this up, though, they should feel free.