[Python-ideas] The async API of the future: yield-from
Greg Ewing
greg.ewing at canterbury.ac.nz
Tue Oct 16 23:14:11 CEST 2012
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.
--
Greg
More information about the Python-ideas
mailing list