[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.
(nitpick):
"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?
(substance):
"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.
-jJ
More information about the Python-Dev
mailing list