Guillaume Chereau wrote:
But what I don't really like with it, is that when you start to write coroutines, you have to use yield every time you call an other coroutine,
Yes, but that's unavoidable as long as you're faking things with generators instead of using real threads, unless some other construct is introduced that's tantamount to 'yield' by another name -- and then you have to remember to use that. Yes I though about this idea, like adding an attribute to a function to tell the interpreter to magically yield its result, but that totally break the mental parsing of the code (not talking about
On Tue, Feb 17, 2009 at 1:44 PM, Greg Ewing
and it make the code full of yield statement ; the proposal if adopted would make it even worst.
I don't see how it would be any worse. Your code at first glance looks incomprehensible to me -- how am I supposed to know that the first 'yield' is a blocking operation while the second one is returning a value? It relies on obscure conventions implemented by some kind of wrapper that you have to learn about.
I Agree, and I don't like it either. It was just the easer way I found to implement micro threads using generators. The proposal would indeed make things more logical, specially if we can use 'return' into the generators. The point I wanted to make was that then we need to write "yield from" every time we call a coroutine from an other one, that is probably a lot, and so made me unhappy about the syntax. In the context of a coroutine, 'yield from' means : "we start this other coroutine, and return to the current coroutine when it is done", and I was expecting the syntax to somehow express this idea. On the other hand, the other usage of "yield from" (to replace : "for x in a: yield x") is totally fine. I tried to think of some other keywords to suggest that would suite both usages, but couldn't find anything. Best regards, Guillaume