[Python-Dev] PEP 340 -- concept clarification

[Guido van Rossum]

[Guido]
> > 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).

[Raymond Hettinger]
> 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.

Good idea. I'm kind of stuck for time (have used up most of my Python
time for the next few weeks) -- if you or someone else could volunteer
some text I'd appreciate it.

> 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).

Right. The PEP started with me not worrying too much about motivation
or use cases but instead focusing on precise specification of the
mechanisms, since there was a lot of confusion over that. Now that's
out of the way, motivation (you might call it "spin" :-) becomes more
important.

> Essentially, having generators as block drivers is the base proposal.
> Everything else is an elaboration.

Right.

> Someone mentioned "suite" as a suitable alternative.  That word seems to
> encompass the same conceptual space without encroaching on existing
> variable and argument names.

Alas, the word "suite" is used extensively when describing Python's syntax.

> 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.

A for-loop without a "continue EXPR" in it shouldn't need to change at
all; the tp_iternext slot could be filled with either __next__ or next
whichever is defined.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)