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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4