[Python-Dev] PEP 340 -- concept clarification

[Guido van Rossum]

[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/)