I find it odd that it both warns and then errors (the error means itdoesn't change, and thus the warning is incorrect)

Consider moving the check up the call stack one level toset_layout_engine such that only one of the error or warning occur.

I think this is over-reach here. People are allowed to change layout engines.

The problem is if people have set the layout engine and then specifically callplt.tight_layout, usually because they are copying and pasting magic commands, and then wonder why constrained layout got clobbered. This check should be in thetight_layout method, not every time the user uses the API to switch the engine.

I'm not sure what@ksunden was referring to wrt to an error - it is very possible to call tight_layout without an error, so maybe the test was malformed.

That makes sense, thank you.

Regarding the error, there was a possibility of a newUserWarning immediately followed by aRuntimeError fromfigure.set_layout_engine.

I was referring to a specific test that was included which had both a warning and an error with pytest checks for both. However in the event an error gets raised, the warning is pointless as that means the layout does not get changed.

I agree that I'm not sure it should warn quite so eagerly, but honestly not convinced it should warn fortight_layout either... that seems like a pretty explicit "I want a tight layout" call, so not sure why we are looking to warn that it is doing exactly what is asked.

It feels like that is just as likely to warn users who expect it than it does to catch users who don't expect that behavior.

but honestly not convinced it should warn for tight_layout either... that seems like a pretty explicit "I want a tight layout" call, so not sure why we are looking to warn that it is doing exactly what is asked.

If someone at the top of the code saysplt.figure(layout='constrained') and then at the bottom of the code saysplt.tight_layout() I think it is likely they have made a mistake.