[Python-Dev] PEP 343 - Abstract Block Redux

[Delaney, Timothy C (Timothy)]

Shane Hathaway wrote:

> PEP 340 is very nice, but it became less appealing to me when I saw
> what  it would do to "break" and "continue" statements.

Absolutely. I really liked PEP 340, but two things stood out to me as
being flawed:

1. Looping - it took a while for me to realise this was bugging me - the
unintuitive behaviour of break and continue clarified it for me.

2. Not re-raising exceptions automatically. I actually proposed at one
point that any exception should be re-raised at the end of the iterator
finalisation unless another exception was raised (not StopIteration,
etc). I still continue to support this. It also deals with the
control-flow issue (being hidden).

PEP 3XX has some other nice things. I have two opposing views on
for-loops supporting finalisation of iterators though:

1. for-loops should support finalisation. However, in that case every
iterator should be finalisable by default, and you should have to go out
of your way to prevent it (or prevent forced exhaustion of the
iterator). I think there's zero chance of this proposal being accepted
;)

2. for-loops should not support finalisation at all, and if you want
finalisation semantics you need to enclose the for-loop in a do/with
statement.

I think the most important thing is that the semantics must be
absolutely clear to someone looking at the code for the first time,
without knowing the particulars of the statement being used. To me that
suggests that the following 3 factors are the most important:

1. Non-looping semantics. Looping semantics require me to think more
about the actual behaviour in the presence of break/continue.

2. An exception raised in the body of the statement must be propagated
outside of the statement. I'm willing to accept another exception being
raised in its place, but in that case I think it would be a good idea to
chain the exceptions in some way. In any case, if the body of the
statement terminates abnormally, it should not be possible for the
statement to change that abnormal exit.

3. There should be a single statement (other than try...finally) that
has finalisation semantics i.e. for-loop doesn't.

Tim Delaney