Hi, Like Justin, I'm happily using asyncio for 3 years now. After discussing with people during pycon-fr and a colleague who just started working on asyncio, I'd like to share a few thoughts I collected (and hope I won't make things more confusing).
I have the feeling that new users can not understand the "scope" of asyncio when reading the doc/api. Some see asyncio as a "new framework to do high performance concurrency" and some others as "the implementation in python of that new programming paradigm everybody talks about" (aka "python trying to compete against go"). Seeing asyncio as a low-level engine is unpleasant because you expect that porting your app to asyncio should be as easy as adding a couple of "async" and "await" keywords in front of blocking calls. It leads to "see how curio does it, it's way more convenient" or even worse: "I'd like to `$ pip install uvloop sanic` and get a faster flask app according to random-bench for free". Seeing asyncio as a framework is confusing because you see the loop as the "app singleton", and start to assume things like: - the loop keep tracks of "asyncio" objects: tasks, server instances, transport/protocol pairs, - run_forever() acts as a main() which handle BaseExceptions (Ctrl+C) and program termination (it will shutdown servers, subprocesses, transport/protocols, ...), - you should write and set an exception handler that makes sense to your app, ie: "what exception handler should I write so loop.call_exception_handler() prints the exception to the client of my HTTP app?" - everything goes trough the loop, so you need an instance of the loop everywhere (intuition enforced by the loop keyword arg everywhere), and create everything through the loop instance (create_task, create_connection, etc). - in this situation, you need get_event_loop() to return a context-aware result (= the loop running the current task), think that everything run inside a task (like on the system everything runs in a process/thread), and eventually you may want task-local storage and context (for instance, a resource or callback created in the task should be canceled when the task is canceled). - the factory methods make you think that you should describe your program as a set of transport/protocols pairs that should be working together... then you get confused because you don't really use coroutines which seem to be a big thing in asyncio world. Overall, I think that the doc is not the only issue, and that the asyncio ecosystem lacks of an actual framwork which enforces a structure for asyncio-based programs. I would love to have the time (and experience, and ...) to write a library which fills those gaps: - provide a few event loop policies (for multi-process or multi-thread apps), - handle graceful termination of long-lived objects, manages task cancellation and exceptions, etc - enforce the use of high-level objects only: streams rather than protocol/transports, - discourage the use of futures in favor of synchronization primitives and coroutines (rather than functions returning Futures), - hide the loop as much as possible, hence provide things like call_at() and call_later() as functions, - provide some devtools abstracting the low-level parts (understandable "tracebacks" !) and making coroutine objects first class citizens (which I try with asynctest). Cheers, Martin 2016-10-30 23:54 GMT+01:00 Glyph Lefkowitz <gl...@twistedmatrix.com>: > > On Oct 30, 2016, at 3:00 PM, Donald Stufft <don...@stufft.io> wrote: > > > On Oct 30, 2016, at 5:36 PM, Guido van Rossum <gu...@python.org> wrote: > > But if you want HTTP, you really should use aiohttp, not some crappy > version that we might supply in the stdlib. There's nothing > dishonorable about using a 3rd party package! > > > > Maybe it would make sense to use aiohttp or something to explain the > concepts of AsyncIO instead of restricting it to just what’s in the > standard library? We have pip shipped w/ Python now and the venv module > exists, so for most people installing aiohttp into a virtual environment or > something to play with asyncio shouldn’t be a big deal. > > To be clear, I don’t mean try to extensively document aiohttp, but rather > use it as a real-ish world introduction to asyncio for folks. > > > Just as a data-point for this, I've been doing a few Twisted tutorials > lately and we have taken a new tack which is to use Klein < > https://github.com/twisted/klein> and Treq <https://github.com/twisted/ > treq> as real-world examples rather than restrict ourselves to what's in > Twisted proper. This has been a _huge_ success in terms of > comprehensibility for newcomers; the concrete example that you can make a > browser talk to is much easier to explain than the highly abstract > "example" Deferreds that we have used in the past. Some of the students at > such tutorials would say stuff like "Actually I wanted to do something with > IRC and IMAP, not a web app, but this gave me a much clearer idea of how to > approach it." > > So I think having asyncio's tutorial work this way would probably be a big > win. > > -glyph > > -- Martin <http://www.martiusweb.net> Richard www.martiusweb.net
