Ron Adam <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > It's not a matter of 'will they be finalized', but instead a matter of > > 'will they be finalized in a timely manner'. From what I understand; > > upon garbage collection, any generator-based resource will be finalized > > via __exit__/next(exception)/... and any class-based resource will have > > its __del__ method called (as long as it is well-behaved), which can be > > used to call __exit__... > > I should have said "...should not finalize at the end of the for loop". > With generators, you may not want them to finalize before you are done > with them, and the same with class's.
So you don't use them with a structure that greedily finalizes, and you keep a reference to the object exterior to the loop. Seems to be a non-issue. > > That is the long-standing nested loops 'issue', which is not going to be > > solved here, nor should it be. > > We may not find a solution today, but where should it be addressed if > not here? > > I don't really see the general issue of breaking out of loops as a > problem, but was just addressing where it overlaps blocks and weather or > not blocks should loop. The argument over whether blocks should loop, I believe has been had; they should. The various use cases involve multi-part transactions and such. > > 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). > > > > Perhaps something like... > > > > while ... label 'foo': > > for ... in ... label 'goo': > > block ... label 'hoo': > > if ...: > > #equivalent to continue 'hoo' > > continue > > elif ...: > > continue 'goo' > > elif ...: > > continue 'foo' > > else: > > break 'foo' > > > > Does this solve the nested loop problem? Yes. Do I like it? Not > > really; three keywords in a single for/block statement is pretty awful. > > On the upside, 'label' doesn't need to be a full-on keyword (it can be a > > partial keyword like 'as' still seems to be). > > How about this for breaking out of all loops at once. > > class BreakLoop(Exception): > """break out of nested loops""" > > try: > for x in range(100): > for y in range(100): > for z in range(100): > if x == 25 and y==72 and z==3: > raise BreakLoop > > except BreakLoop: pass > print 'x,y,z =', x,y,z > > > Sometimes I would like a "try until <exception>:" for cases like this > where you would use "except <exception>:pass". 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. A real solution to the problem should (in my opinion) allow the breaking of or continuing to an arbitrary for/while/block. Humorously enough, Richie Hindle's goto/comefrom statements for Python ("not to be used in production code") would allow 90% of the necessary behavior (though the lack of timely finalization would probably annoy some people, but then again, there is only so much one can expect from a module written as a working April Fools joke over a year ago). - 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