[Python-ideas] The async API of the future: yield-from

[Calvin Spealman]

On Tue, Oct 16, 2012 at 5:14 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 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.

Practically speaking, that is nice. But, are there use cases for
multiple schedulers we should support?

I also like the idea of the scheduler being an iterable, and thus
itself being something you can schedule. Turtles all the way down.

> 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.

I don't follow the part about "found implicitly using dynamic
scoping". What do you mean?

In my model, the tasks never find the scheduler at all. They
don't directly access it at all.

> --
> Greg
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy