[Python-Dev] PEP 340 - possible new name for block-statement

Jim Jewett jimjjewett at gmail.com
Fri Apr 29 16:43:01 CEST 2005

Nick Coghlan:

> Python offers two variants on the basic iterative loop.

>    "for NAME in EXPR:" skips the finalisation step. At loop 
> completion, a well-behaved iterator may still contain additional values.

>   "for NAME from EXPR:" enforces finalisation of the iterator.
> ... At loop completion, a well-behaved [finalizing] iterator is 
> always completely exhausted.

   "from" isn't really different from "in".  Perhaps

    for NAME inall EXPR:
    for NAME draining EXPR:
    for NAME finalizing EXPR:    # too hard to spell, because of s/z?


"finalized or not" is a very useful distinction, but I'm not sure it 
is something the user should have to worry about.  Realistically, 
most of my loops intend to drain the iterator (which the compiler 
knows because I have no "break:".  Regardless of whether I 
use a break, I still want the iterator cleaned up if it is drained.

The only thing this second loop form does is set a flag saying 

   "No, I won't continue -- and I happen to know that no one else 
    ever will either, even if they do have a reference that prevents
    garbage collection.  I'm *sure* they won't use it."  

That strikes me as a dangerous thing to get in the habit of saying.

Why not just agressively run the finalization on both forms when the
reference count permits?

> This form supports block management operations, 

And this seems unrelated to finalization.  I understand that as an
implementation detail, you need to define the finalizers somehow.
But the decision to aggressively finalize (in some manner) and 
desire to pass a block (that could be for finalization) seem like 
orthogonal issues.


More information about the Python-Dev mailing list