Thanks!

Should the api change now be adapted as well?

Hmmm, I don't think I put in an API change note for the original deprecation, which was an oversight.

So now that I think about this a bit more, do we really want to get rid of figure.set_tight_layout()? That is used massively in the wild.

I'd definitively get rid of get/set_constrained_layout_pads(). That's too specific for a figure method. But we're not in a hurry let's go an normal deprecation cycle here, including a pending round.

set_tight_layout/set_constrained_layout: In the very long run, we want to get rid of it because of the duplicate API. But there are 7.5k usages on GitHub, so I think a deprecation would be too annoying. I think we have to give a long lead to let it grow out to some extent.

• This should be marked as 'discouraged' like we did with figure(tight_layout=True).
• Maybe we want to set a PendingDeprecationWarning but without a timeline for the actual deprecation. The pending warning will usually only affect downstream libraries but not end-users. It's good if at least libraries have moved away from it, so that we can actually deprecate if we choose to without downstream libs annoying users with non-actionable deprecation warnings.

OK, so left the pending deprecations in, but changed the deprecation note to say that set_tight/constrained_layout are discouraged rather than that they will be deprecated.