[Python-ideas] The async API of the future: yield-from
ironfroggy at gmail.com
Tue Oct 16 17:27:54 CEST 2012
On Tue, Oct 16, 2012 at 3:45 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Calvin Spealman wrote:
>> If we allow spawn(task())
>> then we're not getting nice tracebacks anyway, so I think we should
>> future1 = yield task1() # spawn task
>> future2 = yield task2() # spawn other task
> I don't think it's necessary to allow 'yield task' as a
> method of spawning in order to get nice tracebacks for
> spawned tasks.
Necessary, no. But I think it feels obvious that you yield things you are
waiting on, and so you want to start a task if you yield it. Also, its
going to be a common primitive, so I think it should be very easy and
clear to write.
> In the Task-object-based system I'm thinking about, if
> an exception reaches the top level of a Task, it gets
> stored in the Task object until another task wait()s
> for it, and then it continues to propagate.
> This makes sense, because the wait() establishes a
> task-subtask relationship, so the traceback should
> proceed from the subtask to the waiting task.
What if two tasks call wait() on the same subtask which raises an
error? I think we should let errors propagate through yield-from,
primarily. That's what it exists for.
>> Both are primitives we
>> need to support as first-class operation. That is, without some wrapper
>> like spawn().
> 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? We might want to
allow multiple schedulers, and tasks shouldn't know who their
scheduler is (right?) so that is another advantage of "yield task()"
> Python-ideas mailing list
> Python-ideas at python.org
Read my blog! I depend on your acceptance of my opinion! I am interesting!
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
More information about the Python-ideas