[Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Josiah Carlson
jcarlson at uci.edu
Sun May 8 18:32:03 CEST 2005
Ron Adam <rrr at ronadam.com> 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
More information about the Python-Dev
mailing list