[Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)

[Josiah Carlson]

Nick Coghlan <ncoghlan at gmail.com> wrote:
> Josiah Carlson wrote:
> > The argument over whether blocks should loop, I believe has been had;
> > they should.  The various use cases involve multi-part transactions and
> > such.

[snip looping block discussion]

> For the one good use case for a user defined loop (auto_retry), I initially 
> suggested in my redraft that there be a way of denoting that a given for loop 
> gives the iterator the opportunity to intercept exceptions raised in the body of 
> the loop (like the PEP 340 block statement). You convinced me that was a bad 
> idea, and I switched to a simple iterator finalisation clause in version 1.2.

Well then, I guess you have re-convinced me that the block statement
probably shouldn't loop.

> Even with that simplified approach though, *using* auto_retry is still very easy:
> 
>    for attempt in auto_retry(3, IOError):
>        stmt attempt:
>            do_something()
> 
> It's a little trickier to write auto_retry itself, since you can't easily use a 
> generator anymore, but it still isn't that hard, and the separation of concerns 
> (between iteration, and the customised control flow in response to exceptions) 
> makes it very easy to grasp how it works.

Great.  Now all we need is a module with a handful of finalization
generators, with all of the obvious ones already implemented.


> >>>The closest thing to a generic solution I can come
> >>>up with would be to allow for the labeling of for/while loops, and the
> >>>allowing of "break/continue <label>", which continues to that loop
> >>>(breaking all other loops currently nested within), or breaks that loop
> >>>(as well as all other loops currently nested within).
> 
> Or, we simply have user defined statements which are not themselves loops, and 
> use them to create named blocks:

[snipped code to protect the innocent]

> This has the benefit that an arbitrary block of code can be named, and a named 
> TerminateBlock used to exit it.

Scary.


> > That is a mechanism, but I like it even less than the one I offered. 
> > Every time that one wants ot offer themselves the ability to break out
> > of a different loop (no continue here), one must create another
> > try/except clause, further indenting, and causing nontrivial try/except
> > overhead inside nested loops.
> 
> Ah well, that criticism applies to my suggestion, too. However, I suspect any 
> such implementation is going to need to use exceptions for the guts of the flow 
> control, even if that use isn't visible to the programmer.

Not necessarily.  If I were implementing such a thing; any time
arbitrary break/continues (to a loop that isn't the deepest) were used
in nested loops, I would increment a counter any time a loop was entered,
and decrement the counter any time a loop was exited.  When performing a
break/continue, I would merely set another variable for which loop is
the final break/continue, then the interpreter could break loops while
the desired level/current level differed, then perform a final
break/continue depending on what was executed.

No exceptions necessary, and the increment/decrement should necessarily
be cheap (an increment/decrement of a char, being that Python limits
itself to 20 nested fors, and probably should limit itself to X nested
loops, where X < 256).


 - Josiah