> But there are several separable proposals in the PEP. Using "continue > EXPR" which calls its.__next__(EXPR) which becomes the return value of > a yield-expression is entirely orthogonal (and come to think of it the > PEP needs a motivating example for this). > > And come to think of it, using a generator to "drive" a block > statement is also separable; with just the definition of the block > statement from the PEP you could implement all the examples using a > class (similar to example 6, which is easily turned into a template).
I think that realization is important. It would be great to have a section of the PEP that focuses on separability and matching features to benefits. Start with above observation that the proposed examples can be achieved with generators driving the block statement. When the discussion hits comp.lang.python, a separability section will help focus the conversation (there's a flaw/issue/dislike about feature x; however, features y/z and related benefits do not depend on x). Essentially, having generators as block drivers is the base proposal. Everything else is an elaboration. > > By comparision, g.throw() or g.close() are trivially simple approaches > > to generator/iterator finalization. > > But much more clumsy to use since you have to write your own try/finally. Sometimes easy makes up for clumsy. > > In re-reading the examples, it occurred to me that the word "block" > > already has meaning in the context of threading.Lock.acquire() which has > > an optional blocking argument defaulting to 1. > > Yeah, Holger also pointed out that block is a common variable name... :-( Someone mentioned "suite" as a suitable alternative. That word seems to encompass the same conceptual space without encroaching on existing variable and argument names. Also, "suite" reads as a noun. In contrast, "block" has a verb form that too easily misconnects with the name of the block-iterator expression -- what comes to mind when you see block sender() or block next_message(). Performance-wise, I cringe at the thought of adding any weight at all to the for-loop semantics. The current version is super lightweight and clean. Adding anything to it will likely have a comparatively strong negative effect on timings. It's too early for that discussion, but keep it in mind. That's pretty much it for my first readings of the PEP. All-in-all it has come together nicely. Raymond _______________________________________________ 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/archive%40mail-archive.com