[Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
jcarlson at uci.edu
Mon May 9 08:31:05 CEST 2005
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:
> 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.
> > 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).
More information about the Python-Dev