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 Anssi.Kääriäinen, amaury.forgeotdarc, benjamin.peterson, docs@python, isoschiz, ncoghlan, pconnell, pitrou, vstinner
Date 2013-04-20.15:53:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1366473206.2623.1.camel@fsol>
In-reply-to <1366470740.88.0.874457532153.issue17468@psf.upfronthosting.co.za>
Content
> We *don't care* if the generator *would* have caught the thrown
> GeneratorExit, we only care about ensuring that finally blocks are
> executed (including those implied by with statements). So if there
> aren't any finally clauses or with statements in the block stack, we
> should be able to just let the generator and frame get collected (as
> Anssi suggested), without trying to allow execution to complete.

That's a good point.

I'm also contemplating that the generator close() could be done from the
*frame*'s tp_clear, which would sidestep the issue of collect order
entirely: the finally block doesn't actually need the generator to
execute, it only needs the frame and its locals.
History
Date User Action Args
2013-04-20 15:53:29pitrousetrecipients: + pitrou, amaury.forgeotdarc, ncoghlan, vstinner, benjamin.peterson, docs@python, Anssi.Kääriäinen, pconnell, isoschiz
2013-04-20 15:53:29pitroulinkissue17468 messages
2013-04-20 15:53:29pitroucreate