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 have
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
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
semantics of
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 for
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 StopIteration
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
inside
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: it's _not currently
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,
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
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.
Wh?
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 the type
11 matches
Mail list logo
