Guido van Rossum wrote:
> Plus, Piet also remarked that the value is silently ignored
> when the generator is used in a for-loop. ... I'd worry that accepting
> "return X" would increase the occurrence of bugs caused by someone
> habitually writing "return X" where they meant "yield X".
Then ha
James Y Knight wrote:
>
> On Oct 8, 2005, at 9:10 PM, Nick Coghlan wrote:
>
>> So, instead of having "return" automatically map to "raise
>> StopIteration"
>> inside generators, I'd like to suggest we keep it illegal to use
>> "return"
>> inside a generator
>
>
> Only one issue with that: i
On Oct 8, 2005, at 9:10 PM, Nick Coghlan wrote:
> So, instead of having "return" automatically map to "raise
> StopIteration"
> inside generators, I'd like to suggest we keep it illegal to use
> "return"
> inside a generator
Only one issue with that: it's _not currently illegal_ to use return
Guido van Rossum wrote:
> On 10/8/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>So, instead of having "return" automatically map to "raise StopIteration"
>>inside generators, I'd like to suggest we keep it illegal to use "return"
>>inside a generator, and instead add a new attribute "result" to Sto
> Guido van Rossum wrote:
> > Before we do this I'd like to see you show some programming examples
> > that show how this would be used. I'm having a hard time understanding
> > where you would need this but I realize I haven't used this paradigm
> > enough to have a good feel for it, so I'm open f
Guido van Rossum wrote:
>>This change would make a huge difference to the practical usability of these
>>generator-based tasks. I think they're much less likely to catch on if you
>>have to write "raise StopIteration( Result )" (or "_return( Result )") all the
>>time.
>>
>>[1] a.k.a. coroutines, w
On 10/7/05, Piet Delport <[EMAIL PROTECTED]> wrote:
> Earlier this week, i proposed legalizing "return Result" inside a generator,
> and making it act like "raise StopIteration( Result )", for exactly this
> reason.
>
> IMHO, this is an elegant and straightforward extension of the current
> semant
Nick Coghlan wrote:
> Phillip J. Eby wrote:
>> Nick Coghlan wrote:
>
[...]
>
>> Last, but far from least, as far as I can tell you can implement all of
>> these semantics using PEP 342 as it sits. That is, it's very simple to
>> make decorators or classes that add those semantics. I don't see
Phillip J. Eby wrote:
> At 09:50 PM 10/7/2005 +1000, Nick Coghlan wrote:
>
>> Notice how a non-coroutine callable can be yielded, and it will still
>> work
>> happily with the scheduler, because the desire to continue execution is
>> indicated by the ContinueIteration exception, rather than by th
At 09:50 PM 10/7/2005 +1000, Nick Coghlan wrote:
>Notice how a non-coroutine callable can be yielded, and it will still work
>happily with the scheduler, because the desire to continue execution is
>indicated by the ContinueIteration exception, rather than by the type of the
>returned value.
Whaaa
Nick Coghlan wrote:
> It ends up looking like this:
>
> def __call__(self, value=None):
> """ Call a generator as a coroutine
>
> Returns the first argument supplied to StopIteration or
> None if no argument was supplied.
> Raises Conti
I'm lifting Jason's PEP 342 suggestions out of the recent PEP 343 thread, in
case some of the folks interested in coroutines stopped following that
discussion.
Jason suggested two convenience methods, .start() and .finish().
start() simply asserted that the generator hadn't been started yet, an
12 matches
Mail list logo
