PEP 340 - possible new name for block-statement
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
Jim Jewett wrote:
Why not just agressively run the finalization on both forms when the reference count permits?
So the iterator is always finalised if the for loop has the only reference? Two problems I can see there is that naming the target of the for loop would prevent it being finalised, and that this would make life interesting when the Jython or IronPython folks catch up to Python 2.5. . . The finalised/not finalised aspect definitely seems to be the key behavioural distinction between the two forms, though. And I think there are legitimate use cases for a non-finalised form. Things like: for line in f: if end_of_header(line): break # process header line for line in f: # process body line With only a finalised form of iteration available, this would need to be rewritten as something like: def header(f): line = next(f) while not end_of_header(line): line = next(f, yield line) for line in header(f): # process header line for line in f: # process body line Considering the above, I actually have grave reservations about *ever* making finalisation the default behaviour of for loops - if I break out of a standard for loop before exhausting the iterator, I would expect to be able to resume the iterator afterwards, rather than having it flushed behind my back. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net
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.
(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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev 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: <block> 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
[Ron Adam]
How about 'serve' as in a server of items from a service?
No, please. This has way too strong connotations with network protocols. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
[Ron Adam]
How about 'serve' as in a server of items from a service?
No, please. This has way too strong connotations with network protocols.
Errr... you're right of course... :-/ (I was thinking *way* to narrow.) I think the context is correct, just need a synonym that isn't already used. provide, provider supply, supplier dispense, dispenser deal, dealer deliver, deliveror or parcel, meter, dish, give, dole, offer, cede... Maybe barrow from a different language? Ron Adam
participants (4)
-
Guido van Rossum -
Jim Jewett -
Nick Coghlan -
Ron Adam