[Cython] CF and finally clause

[Stefan Behnel]

Robert Bradshaw, 24.05.2011 22:07:
> On Tue, May 24, 2011 at 12:33 PM, Vitja Makarov wrote:
>> When I create control flow graph I have to visit finally clause twice.
>> This is required because of different outputs should be generated for
>> success and exception case:
>>
>> try:
>>     a = might_raise()
>> finally:
>>     pass # 'a' might be uninitialized here
>> print(a)  # and definitely defined here
>>
>> So after tracking both cases I have to merge states back because same
>> code is generated for each.

Note that there are also the break, continue and return cases.


>> Maybe it's a good idea to split success/exception case by copying it
>> at PostParse transform?
>
> -1
>
> I don't see any difference compared to merging the states from
>
> if b:
>      a = None
> else:
>      # don't assign to a

The difference is that try-finally executes the exact same code in both 
cases, but both cases are otherwise in completely distinct code paths. In a 
way, it's the opposite of your example, where the same outer code path can 
execute either of the distinct inner code sections.

I'm not so opposed to this proposal. I have been (idly and unfoundedly) 
wondering basically forever if the current way try-finally is implemented 
is actually a good one. I can accept a performance penalty for the 
exception case in both try-finally and try-except, but the normal case in 
try-finally should run as fast as possible. I'm not sure the C compiler can 
always detect what that "normal" case is in order to properly optimise for it.

However, given that there are actually up to four normal cases and only one 
exception case, I also wonder if even Cython can detect what the "normal" 
case should be, and if it's really worth providing a distinct 
implementation in order to optimise it.

Stefan