> so the new syntax would
> not be useful, unless it was something that provided access to the index
> item as a variable, like:
>
> yield foo(i) for i in x
>
> which barely saves you anything (a colon, a newline, and an indent).
Not even that, because you can omit the newline and indent:
> We yield values from inside for loops all over the place, but the
> yielded value is very rarely just the index value (only 1 of 14 yields)
> , but something calculated from the index value, so the new syntax would
> not be useful, unless it was something that provided access to the index
> item
Andrew Koenig wrote:
>> Sure, that would work. Or even this, if the scheduler would
>>automatically recognize generator objects being yielded and so would run
>>the the nested coroutine until finish:
>
>
> This idea has been discussed before. I think the problem with recognizing
> generators a
At 12:01 PM 10/18/2005 +0100, Gustavo J. A. M. Carneiro wrote:
>def show_message(msg):
> win = create_window(msg)
> animate(win, xrange(10)) # slide down
> yield Timeout(3)
> animate(win, xrange(10, 0, -1)) # slide up
> win.destroy()
>
> This obviously doesn't work, because ca
Andrew Koenig wrote:
>> Sure, that would work. Or even this, if the scheduler would
>> automatically recognize generator objects being yielded and so would run
>> the the nested coroutine until finish:
>
> This idea has been discussed before. I think the problem with recognizing
> generators a
> Sure, that would work. Or even this, if the scheduler would
> automatically recognize generator objects being yielded and so would run
> the the nested coroutine until finish:
This idea has been discussed before. I think the problem with recognizing
generators as the subject of "yield" state
On Tue, 2005-10-18 at 09:07 -0400, Jim Jewett wrote:
> Suppose now I want to move the window animation to a function, to
> factorize the code:
>
> def animate(win, steps):
> for y in steps:
> win.move(0, y*20)
> yield Timeout(0.1)
>
> def show_message(msg):
> win = create_window(msg)
>
Gustavo J. A. M. Carneiro wrote:
> I don't suppose there could be a way to make the yield inside the
> subfunction have the same effect as if it was inside the function that
> called it? Perhaps some special notation, either at function calling or
> at function definition?
You mean like a for l
