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

[Ron Adam]

Josiah Carlson wrote:
> 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__...

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.


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

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.

> I am not sure that any solution to the issue will be sufficient for
> everyone involved. 

That's the nature of programming in general isn't it. ;-)


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

Cheers,
Ron_Adam