Author Mark.Shannon
Recipients Demur Rumed, Mark.Shannon, benjamin.peterson, christian.heimes, mark.dickinson, nascheme, ncoghlan, pitrou, rhettinger, serhiy.storchaka, trent
Date 2017-12-04.17:19:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <a2633ab5-5813-7af8-fa7b-e5b41ce12431@hotpy.org>
In-reply-to <1567354.66TbBMzbGb@saraksh>
Content
On 04/12/17 16:56, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka <storchaka+cpython@gmail.com> added the comment:
> 
> Right, this is similar to how the JSR/RET pair was used in for calling the
> finally block.
> 
> It seems the main drawback of duplicating of the finally code is not increasing
> the code size (which can be exponential in degenerate cases), but the problem
> with determining the boundaries of the finally block.

What exactly is the problem?
Why do you need to determine the boundaries of finally blocks?

...

> 
> This is the first step. In the second step I'm going to get rid of dynamic
> PyTryBlock and instructions like SETUP_EXCEPT and POP_BLOCK. I think all
> necessary information can be determined at compile time and saved in an
> auxiliary structure, similarly as line numbers are saved in the packed
> co_lnotab array instead of be set by SET_LINENO instructions. Boundaries of
> finally block could be stored in the same structure. This will make try/except/
> finally virtually zero-overhead.

Fine, but it isn't necessary for this issue. The overhead of try/except 
is already quite low.

> 
> Currently there is other problem with Antoine's PR (I didn't know about them
> when made a review). There is a gap between calling the __enter__ method and
> the SETUP_FINALLY instruction. 

That wasn't a problem with the original patch.
History
Date User Action Args
2017-12-04 17:19:48Mark.Shannonsetrecipients: + Mark.Shannon, nascheme, rhettinger, mark.dickinson, ncoghlan, pitrou, christian.heimes, benjamin.peterson, trent, serhiy.storchaka, Demur Rumed
2017-12-04 17:19:48Mark.Shannonlinkissue17611 messages
2017-12-04 17:19:48Mark.Shannoncreate