"yield from" -> "yield as"?
John Graham wrote:
I'm not sure what I think about redefining the continue keyword, but has anyone already proposed doing "yield as" instead of "yield from"? To me it make that wording makes a little more sense, "OK, you're not yielding as f anymore, now you've silently replaced yourself with g and it's 'as if' g is doing the yielding." "Yield from" makes it clear that all of the values of g will be yielded, but "yield as" makes it clear that things like .send(), etc. will be sent to g and not intercepted by f in any real way. My 2-cents on the bikeshed, -- Carl
Just wanted to politically come out as in favor of painting the bikeshed any damn color, so long as we build it :) In other words, I'm just as supportive of another 'yield' construct as I am 'continue', if it were to serve the same role that's proposed. The main thrust of the 'continue' argument was that many of the criticisms of allowing TCO into the language disappear if we make it explicit, so the user doesn't have to guess. On Sat, May 2, 2009 at 4:47 PM, Carl Johnson <cmjohnson.mailinglist@gmail.com> wrote:
On 02May2009 11:47, Carl Johnson <cmjohnson.mailinglist@gmail.com> wrote: | John Graham wrote: | > There are some alternative designs for this problems that have been | > proposed. SJBrown has proposed a similar syntax, using the two | > keywords 'continue as' instead of simply 'continue'. This would | > further make clear to users unfamiliar with continuations that | > behavior is expected to be different here, and the English still flows | > elegantly. It does, however, reuse the 'as' keyword in an unfamiliar | > way. | | I'm not sure what I think about redefining the continue keyword, but | has anyone already proposed doing "yield as" instead of "yield from"? | To me it make that wording makes a little more sense, "OK, you're not | yielding as f anymore, now you've silently replaced yourself with g | and it's 'as if' g is doing the yielding." "Yield from" makes it clear | that all of the values of g will be yielded, but "yield as" makes it | clear that things like .send(), etc. will be sent to g and not | intercepted by f in any real way. I'm a little uncomfortable with yield as. We've got: import foo as bar from foo import zot as bah with fred() as bah: ... All of these place a new name "bah" into the namespace for further use. "yield as" doesn't, but reads to me like it should. -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ From the back of the research lab, the sound of a large metallic pile of loose objects collapsing, accompanied by a loud "Aaaaiiieeyyrrgghhh!!" from George. A few seconds of silence, then: "I'll have to call you back."
Just wanted to politically come out as in favor of painting the bikeshed any damn color, so long as we build it :) In other words, I'm just as supportive of another 'yield' construct as I am 'continue', if it were to serve the same role that's proposed. The main thrust of the 'continue' argument was that many of the criticisms of allowing TCO into the language disappear if we make it explicit, so the user doesn't have to guess. On Sat, May 2, 2009 at 4:47 PM, Carl Johnson <cmjohnson.mailinglist@gmail.com> wrote:
On 02May2009 11:47, Carl Johnson <cmjohnson.mailinglist@gmail.com> wrote: | John Graham wrote: | > There are some alternative designs for this problems that have been | > proposed. SJBrown has proposed a similar syntax, using the two | > keywords 'continue as' instead of simply 'continue'. This would | > further make clear to users unfamiliar with continuations that | > behavior is expected to be different here, and the English still flows | > elegantly. It does, however, reuse the 'as' keyword in an unfamiliar | > way. | | I'm not sure what I think about redefining the continue keyword, but | has anyone already proposed doing "yield as" instead of "yield from"? | To me it make that wording makes a little more sense, "OK, you're not | yielding as f anymore, now you've silently replaced yourself with g | and it's 'as if' g is doing the yielding." "Yield from" makes it clear | that all of the values of g will be yielded, but "yield as" makes it | clear that things like .send(), etc. will be sent to g and not | intercepted by f in any real way. I'm a little uncomfortable with yield as. We've got: import foo as bar from foo import zot as bah with fred() as bah: ... All of these place a new name "bah" into the namespace for further use. "yield as" doesn't, but reads to me like it should. -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ From the back of the research lab, the sound of a large metallic pile of loose objects collapsing, accompanied by a loud "Aaaaiiieeyyrrgghhh!!" from George. A few seconds of silence, then: "I'll have to call you back."
participants (3)
-
Cameron Simpson -
Carl Johnson -
John Graham