Nick Coghlan <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com