[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:
> >>I think a completely separate looping or non-looping construct would be 
> >>better for the finalization issue, and maybe can work with class's with 
> >>__exit__ as well as generators.
> > 
> > From what I understand, the entire conversation has always stated that
> > class-based finalized objects and generator-based finalized objects will
> > both work, and that any proposal that works for one, but not the other,
> > is not sufficient.
> 
> That's good to hear.  There seems to be some confusion as to weather or 
> not 'for's will do finalizing.  So I was trying to stress I think 
> regular 'for' loops should not finalize. They should probably give an 
> error if an object with an try-finally in them or an __exit__ method. 
> I'm not sure what the current opinion on that is.  But I didn't see it 
> in any of the PEPs.

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__...


> >>Having it loop has the advantage of making it break out in a better 
> >>behaved way.
> > 
> > What you have just typed is nonsense.  Re-type it and be explicit.
> 
> It was a bit brief, sorry about that. :-)
> 
> To get a non-looping block to loop, you will need to put it in a loop or 
> put a loop in it.
> 
> In the first case, doing a 'break' in the block doesn't exit the loop. 
> so you need to add an extra test for that.
> 
> In the second case, doing a 'break' in the loop does exit the block, but 
> finishes any code after the loop.  So you may need an extra case in that 
> case.
> 
> Having a block that loops can simplify these conditions, in that a break 
> alway exits the body of the block and stops the loop.  A 'continue' can 
> be used to skip the end of the block and start the next loop early.
> 
> And you still have the option to put the block in a loop or loops in the 
> block and they will work as they do now.
> 
> I hope that clarifies what I was thinking a bit better.


That is the long-standing nested loops 'issue', which is not going to be
solved here, nor should it be.

I am not sure that any solution to the issue will be sufficient for
everyone involved.  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).

Enough out of me, good night,
 - Josiah