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 at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4