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

Ron Adam rrr at ronadam.com
Fri Apr 29 19:57:25 CEST 2005

Jim Jewett wrote:

>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.
>Python-Dev mailing list
>Python-Dev at python.org
>Unsubscribe: http://mail.python.org/mailman/options/python-dev/rrr%40ronadam.com
How about 'serve' as in a server of items from a service?

    serve NAME from EXPR:

I think this is more descriptive of what it does and will make it easier 
to explain.  It also implies the correct relationship between the block, 
the name, and the expression.

I  think 'block' and 'with' are both *way* too general.  The problem I 
see with 'block' is that the term is often used as a general term to 
describe the body of other statements....  while, for, if, ... etc.

The generator in this case could be called a 'server' which would 
distinguish it from a normal genrator. 

By using 'serve' as a keyword, you can then refer to the expression as a 
whole as a 'service' or a 'resouce manager'.  And a simple description 
of it would be....

     A SERVE statement serves NAME(s) from a SERVER to the following 
statement block.
         (Details of how to use SERVE blocks and SERVERS.)

Ron Adam

More information about the Python-Dev mailing list