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