Robert Bradshaw, 25.05.2011 01:30:
On Tue, May 24, 2011 at 2:17 PM, Carl Witty wrote:
On Tue, May 24, 2011 at 2:04 PM, Stefan Behnel wrote:
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
actual
On Tue, May 24, 2011 at 2:17 PM, Carl Witty wrote:
> On Tue, May 24, 2011 at 2:04 PM, Stefan Behnel wrote:
>> 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 accep
On Tue, May 24, 2011 at 2:04 PM, Stefan Behnel wrote:
> 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
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:
On Tue, May 24, 2011 at 12:33 PM, Vitja Makarov wrote:
> Hi!
>
> 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' m
Hi!
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 a
