The computation of `co_stacksize' by the compiler is known to give only an upper bound estimate.http://bugs.python.org/issue1754094 is an example of fixing a "leak" where every repetition of a statement makes `co_stacksize' bigger by 1.  However, in the whole 3.x series (from at least 3.2), the following simple code, which at runtime requires about 4 or 5 stack slots, leaks 14(!) slots for every `try:' block.  Maybe this should be improved to reduce the extreme size of the leak.def g():    try: pass    except ImportError as e: pass    try: pass    except ImportError as e: pass    try: pass    except ImportError as e: pass    ...i.e. any function that is big enough to contain 6 try: blocks in sequence will have its stack size overestimated by about 70.

PR 1938 tries to balance the stack effect computation for try/except and try/finally. I'm not sure that it is worth backporting.Noised Antoine and Benjamin as people related toissue3021.

I'm against backporting performance improvements which don't fix a severe regression.

This isn't so easy. Seems the simplest way to solve this issue is implementingissue17611.

The WIP pull request PR# 2827 seems to help. The following code prints 86 on python3.6 and 25 withPR 2827 applied.def g():    try: pass    except ImportError as e: pass    try: pass    except ImportError as e: pass    try: pass    except ImportError as e: pass    try: pass    except ImportError as e: pass    try: pass    except ImportError as e: pass    try: pass    except ImportError as e: passprint(g.__code__.co_stacksize)

WithPR 5076 the result of the above example is 10.

Tests originally based on Antoine's tests added forPR 2827.

New changesetd4864c61e3e27e337762dc45e504977299bd5b46 by Serhiy Storchaka in branch 'master':bpo-24340: Fix estimation of the code stack size. (#5076)https://github.com/python/cpython/commit/d4864c61e3e27e337762dc45e504977299bd5b46