[Python-Dev] PEP 340 -- concept clarification

[Raymond Hettinger]

> 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