[Python-Dev] PEP 380 (yield from a subgenerator) comments

[Guido van Rossum]

On Tue, Mar 24, 2009 at 11:03 PM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
>
>> The way I think of it, that refactoring has nothing to do with
>> yield-from.
>
> I'm not sure what you mean by that. Currently it's
> *impossible* to factor out code containing a yield.

That's stating it a little too strongly. Phillip has shown how with
judicious use of decorators and helper classes you can get a
reasonable approximation, and I think Twisted uses something like
this, so it's not just theory. I think the best you can do without new
syntax though is still pretty cumbersome and brittle, which is why I
have encouraged your PEP.

> Providing a way to do that is what led me to invent
> this particular version of yield-from in the first
> place.
>
> I wanted a way of writing suspendable functions that
> can call each other easily. (You may remember I
> originally wanted to call it "call".) Then I noticed
> that it would also happen to provide the functionality
> of earlier "yield from" suggestions, so I adopted that
> name.
>
> But for me, factorability has always been the fundamental
> idea, and the equivalence, in one particular restricted
> situation, to a for loop containing a yield is just a
> nice bonus.
>
> That's what I've tried to get across in the PEP, and
> it's the reason I've presented things in the way I have.

That's all good. I just don't think that a presentation in terms of
code in-lining is a good idea. That's not how we explain functions
either. We don't say "the function call means the same as when we
wrote the body of the function in-line here." It's perhaps a game with
words, but it's important to me not to give that impression, since
some languages *do* work that way (e.g. macro languages and Algol-60),
but Python *doesn't*.

>> It's not just variable references -- I used "scope" as a
>> shorthand for everything that can be done within a function body,
>> including control flow: try/except/finally,
>> continue/break/raise/return.
>
> Same answer applies -- use the usual techniques.
>
> When I talk about inlining, I mean inlining the
> *functionality* of the code, not its literal text. I'm
> leaving the reader to imagine performing the necessary
> transformations to preserve the semantics.

Yeah, so I'm asking you to use a different word, since "inlining" to
me has pretty strong connotations of textual substitution.

>> Maybe you're confusing motivation with explanation? That feedback
>> seems to tell me that the *motivation* needs more work; but IMO the
>> *explanation* should start with this simple model and then expand upon
>> the edge cases.
>
> Perhaps what I should do is add a Motivation section before
> the Proposal and move some of the material from the beginning
> of the Rationale sectiomn there.

Yeah, I think it can easily be saved by changing the PEP without
changing the specs of the proposal.

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