[Guido] > > Where do you see a learning curve for blocks? [Raymond] > Altering the meaning of a for-loop; introducing a new keyword; extending > the semantics of "break" and "continue"; allowing try/finally inside a > generator; introducing new control flow; adding new magic methods > __next__ and __exit__; adding a new context for "as"; and tranforming > "yield" from statement semantics to expression semantics. This isn't a > lightweight proposal and not one where we get transference of knowledge > from other languages (except for a few users of Ruby, Smalltalk, etc).
[Bah, gmail just lost my draft. :-( Trying to reconstruct...] 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 seeing just two of the examples would be enough for most people to figure out how to write their own, so that's not much of a learning curve IMO. > 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. > In section on new for-loop specification, what is the purpose of "arg"? > Can it be replaced with the constant None? No, it is set by the "continue EXPR" translation given just below it. I'll add a comment; other people also missed this. > In "block expr as var", can "var" be any lvalue? Yes. That's what I meant by "VAR1 is an arbitrary assignment target (which may be a comma-separated list)". I'm adding an example that shows this usage. > 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... :-( > In example 4, consider adding a comment that the "continue" has its > normal (non-extending) meaning. I'd rather not, since this would just increase the confusion between the body of the generator (where yield has a special meaning) vs. the body of the block-statement (where continue, break, return and exceptions have a special meaning). Also note example 5, which has a yield inside a block-statement. This is the block statement's equivalent to using a for-loop with a yield in its body in a regular generator when it is invoking another iterator or generator recursively. > The examples should demonstrate the operation of the extended form of > "continue", "break", and "return" in the body of the block. Good point. (Although break and return don't really have an extended form -- they just get new semantics in a block-statement.) I'll have to think about those. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
