Hello, On Fri, 25 Apr 2014 19:27:31 +0100 Gustavo Carneiro <[email protected]> wrote:
[] > I do not know what you mean by "native Python coroutines". I mean the same as this PEP: http://legacy.python.org/dev/peps/pep-0342/ > As far as > I'm aware, there are no "native" Python coroutines. Natively, Python > has generator functions. Asyncio is a library that creates an > illusion of co-routine on top of generator functions. > > If you are complaining about whether or not Python should have native > coroutines, with deep integration with the language itself, then I > think that discussion is out of scope for this list. > > > > > > > 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. > > > > As I said, Task is not executed immiediately upon instantiation, it is > merely _scheduled_ to be executed as soon as you return control to > the main loop. You have plenty of opportunity to initialize things > before the task is executed. And that's neither natural nor obvious. Take for example https://docs.python.org/3.4/library/asyncio-task.html#example-parallel-execution-of-tasks One may think that it's asyncio.wait(), after being scheduled and run itself, causes its argument tasks to be scheduled and run. So, one may want to precreate task list to be passed to wait() at later time, when actually needed. But nope, that's not how it works - tasks will start to run even before passed to wait. > > > 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* ? > > > > I'm not sure what you mean. > > I suspect you want to do something clever and non-standard with Task > and asyncio, and are facing an obstacle due to the way Task schedules > itself for execution. I would like to write alternative asyncio implementation, centered around efficient coroutines support. My implementation would allow to schedule coroutines in event loop directly, but as asyncio doesn't allow that, I would need to provide those asyncio.async() and asyncio.Task() adapters. My initial thought that those would be just identity functions, but oops - it turned out that those function/object have side effects, and such that actually it's pretty hard to both have lean, simple and clean implementation/API, and upstream asyncio compatibility. > I believe this is what normal asyncio users > want. If you are trying to achieve something "less normal", maybe > you can work with the Tulip maintainers to allow instantiating a Task > without it being automatically scheduled for execution. For > instance, by adding a keword parameter to the constructor: > > Task(mygenerator(), schedule_for_execution=False) Well, I know too little of asyncio to suggest something like that, what I'm trying to achieve first is to understand why asyncio was designed/implemented this way. From my point of view however, the best solution would be to add a loop method allowing to schedule a coroutine/generator directly. Implementation for mainline asyncio would be trivial wrapping it with Task(), but other implementations could implement just e.g. coroutine support w/o extra wrappers and layers. -- Best regards, Paul mailto:[email protected]
