Hello, On Thu, 24 Apr 2014 20:32:43 -0700 Guido van Rossum <[email protected]> wrote:
> Paul, > > I recommend that you take a step back and look at it from a different > angle. I appreciate BDFL's taking time to respond to this! I'm a novice to this and definitely so far look from one angle (specifically, how to use asyncio with coroutines and don't let other stuff like Future's stay in the way). I may imagine that discussed interface/behavior for Task's come from requirements to interact with other asyncio entities. I appreciate helping to understand which and why exactly. > > If you have a coroutine that is waiting for you to tell it to run > again, you should use a Future. The coroutine should use "yield from" > on it, and in the other code, when you are ready to make it run, you > call set_result() (or set_exception()) on that same Future. ... Unfortunately this description doesn't provide much insight to me ;-(. Hope it's not because I'm dumb, but because, as many presentations mention, details of async programming in general, and asyncio module in particular, may be not obvious to develoeprs who are used to a conventional programming model, so people would need to spend time to learn it. Back to your description, I'm not even sure which of my questions it answers. Granted, there were few of them, and actually after I wrote the original mail, it occurred to me, that I had all data to answer one of the questions I posed: "What is the simplest possible way to schedule a coroutine to be run?". But the answer was so unexpected, so ambush-like, that didn't occur to me at that time: The way to schedule a coroutine is to instantiate a Task object for it. So, the main question which remains is: How an instantiation of object may have such a strong side effect? Why such an object is modestly called Task, and not SelfSchedulingTaskViolatingExplicitIsBetterThanImplicitPrinciple? Actually, my first question was: is it ever documented somewhere? And re-reading asyncio docs, I found a proverbial example of fineprint. So, there's section "18.5.2.4. Task" (https://docs.python.org/3.4/library/asyncio-task.html#task), it has subsection "18.5.2.4.1. Example: Parallel execution of tasks". From the name it's clear that the subsection contains just an example and commentary to it. So, after a long example block, in very last short line of the subsection - a place where few people will pay enough attention to it, I found that sacral phrase - "A task is automatically scheduled for execution when it is created. The event loop stops when all tasks are done." > > That's all there is to it! > > Good luck, > > --Guido > > > On Thu, Apr 24, 2014 at 5:32 PM, Paul Sokolovsky <[email protected]> > wrote: > > > Hello, > > > > This must be FAQ, but: 1) google can't get search results right; 2) > > people gotta ask that again, again, and again, so here it goes. > > > > Why Task objects in asyncio are not callable? Just studying > > asyncio, it becomes clear that it's core is loop which runs > > callbacks from a queue. So, how do we integrate coroutines via > > generators into that? Obvious, we add an adapter object which > > translates call protocol into generator protocol, voila. > > > > Now, why that undocumented _step() method, worse, why is it > > scheduled to be called in *Task constructor*? How just creating a > > task object makes it scheduled? Why are users denied ability to > > schedule Tasks as they see fit? In general, why all this tight > > coupledness between event loop and Tasks? > > > > Where this comes from: I'm looking for the simplest possible way to > > schedule a coroutine to be run. run_until_complete(), > > asyncio.wait() - too complicated and bloated ways for such a simple > > task (and that's what asyncio docs give in examples). > > > > Thanks. > > > > > > > -- > --Guido van Rossum (python.org/~guido) -- Best regards, Paul mailto:[email protected]
