This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Demur Rumed, Mark.Shannon, benjamin.peterson, christian.heimes, mark.dickinson, nascheme, pitrou, rhettinger, serhiy.storchaka, trent, vstinner
Date 2017-07-24.08:09:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1500883745.86.0.991732879843.issue17611@psf.upfronthosting.co.za>
In-reply-to
Content
So, the approach of duplicating finally blocks tends to lead to a non-trivial bytecode increase.  There is even a potential combinatorial explosion with nested "try..finally" block:

def f():
    try:
        ...
    finally:
        try:
            ...
        finally:
            # etc.

Such a chain of N nested "finally"s will emit O(2**N) opcodes.

I'm not sure it's a pratical concern but I find it is detrimental to the readibility of bytecode (which is a nice thing to have when doing low-level debugging or tweaking).  I think we can massage the PR to remove the "finally" block duplication while keeping the predictable stack effect.
History
Date User Action Args
2017-07-24 08:09:05pitrousetrecipients: + pitrou, nascheme, rhettinger, mark.dickinson, vstinner, christian.heimes, benjamin.peterson, trent, Mark.Shannon, serhiy.storchaka, Demur Rumed
2017-07-24 08:09:05pitrousetmessageid: <1500883745.86.0.991732879843.issue17611@psf.upfronthosting.co.za>
2017-07-24 08:09:05pitroulinkissue17611 messages
2017-07-24 08:09:05pitroucreate