Hello, On Fri, 25 Apr 2014 18:07:02 +0100 Gustavo Carneiro <[email protected]> wrote:
[] > > 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." > > > > > Because the whole point of Task is to be scheduled for execution, it > makes no sense to instantiate a Task and then have to call a separate > method the schedule it. What a fresh perspective! Indeed, why not take all objects and make them do "the most expected action" by default right away. Why all those messy methods on Popen - it can just slurp any output on construction and terminate the child process, HttpRequest can do a GET and slurp entire response, etc. > If you do not want to schedule it _right > now_ then what is the point of creating the Task in the first place? Because asyncio forces me! Advertised as native Python async framework, it doesn't even allow to use directly native Python coroutines, and instead appears to be attempt to marry Twisted and Node.JS, with native Python features being second-class citizens requiring being disguised into those projects' stuff, which has questionable traits, hinting of its heritage. > I suspect your expectactions are tainted by the previous knowledge of > the threading API, which has a separate Thread.start() method. I My expectations are "tainted" by: 1) basic programming rule of thumb that you first initialize things properly, and then execute them; 2) intuitive feeling, and even explicit knowledge, of Python's "explicit is better than implicit" principle; 3) acquaintance (cursory, I have to admit) with many-year history of using generators/coroutines for async cooperative multitasking, and desire to use that using standardized API asyncio promotes. > think it makes _some_ sense that Thread objects do not start the > actual thread automatically, since threads are preemptive and prone > to race conditions, and you may want to store the Thread object in > some data structure _before_ the thread actually begins executing. > With asyncio.Task, even if the task is scheduled to be executed, it > is guaranteed not to be executed until you reach "yield from" > statement, so you have plenty of opportunity to any setup prior to > the task executing. Let's sum up what you're saying here: asyncio Task implementation, by relying on internal asyncio implementation details (so, naive users who will get fixation on such behavior will fail miserably in other contexts), violates "Explicit is better than implicit" principle *just because it can* ? -- Best regards, Paul mailto:[email protected]
