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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
