On Fri, Oct 19, 2012 at 4:29 PM, Greg Ewing email@example.com wrote:
Calvin Spealman wrote:
I think it is important that this is more than convention. I think that we need our old friend TOOOWTDI (There's Only One Obvious Way To Do It) here more than ever.
This is part of the reason that I don't like the idea of controlling the scheduler by yielding instructions to it. There are a great many ways that such a "scheduler instruction set" could be designed, none of them any more obvious than the others.
So rather than single out an arbitrarily chosen set of operations to be regarded as primitives that the scheduler knows about directly, I would rather have *no* such primitives in the public API.
But you have that problem anyway. In your current style you write things like this:
I don't see how this decouples the call site of the primitive from the scheduler any more than if you were to write e.g. this:
In fact, you can write it in your current framework and it would have the exact same effect! That's because block() returns None, so it comes down to calling block(self.queue) and then yielding None, which is exactly what happens in the first form as well. And even if block() were to return a value, since the scheduler ignores the return value from next(), it still works the same way. Not that I recommend doing this just because it works -- but if we liked the second form better, we could easily implement block() in such a way that you'd *have* to write it like that.
So, I don't see what we gain by writing it the first way.