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

[Josiah Carlson]

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