On Tue, Mar 24, 2009 at 11:03 PM, Greg Ewing <greg.ew...@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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com