[Python-Dev] PEP 340 - possible new name for block-statement
rrr at ronadam.com
Fri Apr 29 19:57:25 CEST 2005
Jim Jewett wrote:
>>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
>Python-Dev mailing list
>Python-Dev at python.org
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
(Details of how to use SERVE blocks and SERVERS.)
More information about the Python-Dev