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.

The main purpose of this issue (getting rid of "pseudo exceptions" in the 
interpreter) will be achieved in any case.

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.

In the third step we could generate duplicates of finally blocks. This will be 
easier if other changes already applied and tested.

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. If the exception is raised in the gap, the 
__exit__ method will be never called. For example:

    a = []
    with CM() as a[0]: # IndexError
        ...

I still haven't fixed this problem. Maybe the simplest solution would be to 
return the SETUP_WITH instruction which calls __enter__ and creates the finally 
block prior to saving the result of __enter__.