Calvin Spealman wrote:
What if two tasks call wait() on the same subtask which raises an error?
That would be disallowed. A given Task would only be allowed to have its wait() method called once.
The reason for this restriction is because of the way tracebacks are attached to exception objects in Python 3, which means that exceptions are effectively single-use now. If it weren't for that, the exception could simply be raised in *both* waiters.
I think we should let errors propagate through yield-from, primarily. That's what it exists for.
Yes, and that's exactly what my wait() mechanism does. You call the wait() method using yield-from.
The important idea is that just because you spawn a task, it doesn't necessarily follow that you want to be regarded as the *parent* of that task and receive its exceptions. That only becomes clear when you wait() for it.
In my system, spawn() isn't a wrapper -- it *is* the primitive way to create an independent task. And I think it's the only one we need.
It has to know what scheduler to talk to, right?
Yes, but in my world, there is only *one* scheduler.
I understand that not everyone thinks that's a good idea, and I'm thinking about ways to remove that restriction. But I'm not yet sure that it *should* be removed even if it can. It seems to me that having multiple schedulers is inviting many of the same problems as having multiple event loops, and this whole disussion is centred on the idea that there should only be one of those.
Just to be clear, I'm not saying there should only be one scheduler *implementation* in existence -- only that there should only be one *instance* of some scheduler implementation in any given program (or thread, if you're using those). And there should be a standard interface for it and an agreed way of finding the instance.
What you're saying is that the standard interface should consist of yielded instructions and the instance should be found implicitly using dynamic scoping. This is *very* different from the kind of interface used for everything else in Python, and I'm not yet convinced that such a large amount of weirdness is justified.