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