Mailman 3 October 2016 - Async-sig

A modest terminological proposal
by Nathaniel Smith 29 Dec '16

29 Dec '16

I've found that when talking about async/await stuff recently, I've mostly dropped the word "coroutine" from my vocabulary and replaced it with "async function". I'm writing to suggest that we might want to make this switch as a community, and do it now, before the next 10x increase in the async/await userbase. Rationale: *Consistency*: If the only two words to keep track of were function vs coroutine, that would be one thing. But here's a list of syntax constructs we have now, and how we talk about them in English: with -> applies a *context manager* to a *with block* async with -> applies an *async context manager* to an *async with block* for -> does a *loop* over an *iterator* async for -> does an *async loop* over an *async iterator* def + yield -> makes a *generator* async def + yield -> makes an *async generator* [... for ...] -> is a *comprehension* [... async for ...] -> is an *async comprehension* def -> creates a *function* async def -> creates a *coroutine* One of these is not like the others. Why? It's a pointless toe-stub for newcomers. *Expressivity:* Once I started talking about async functions, I've found my vocabulary suddenly expanding with useful new bonus terms, like "async method" (= an async def inside a class body), or "async callable" (= any callable that returns an awaitable, emphasizing the duck type rather than the concrete type). *Approachability*: What is a "coroutine" anyway? Is it like a monad? Am I going to have to learn about endofunctors and continuations next? Of course we've all gotten used to the term now so we don't notice, but for a new user this is an obviously jargony "if you don't have a PhD then this isn't *for* you" kind of word. It's not hospitable. Plus, it emphasizes the implementor under-the-hood point of view, not the user point of view. (Which is totally understandable! Because we're just now transitioning from the internal implementors hacking things out phase to the broad general user base phase, but that's why we should fix this now.) For an end-user, especially one starting out, they don't need to know or care about all the coroutine stuff that async/await is using to make the magic happen, they can learn that later. To get started, all you need to know is that you do async stuff by using async functions and sticking an 'await' onto your I/O calls. A lot of work went into abstracting away that magic and giving it a friendly Python syntax; the English syntax should follow suit. *Accuracy*: Speaking of jargon, the term "coroutine" *is* an existing piece of jargon in computer science, and our term and their term don't quite match up. This isn't a huge deal, but it's unnecessary confusion. According to Wikipedia I guess technically we don't even have "true" coroutines, just "semicoroutines"? And every generator has just as much claim to being a coroutine-in-the-CS-sense as an async function does, but when we say coroutine we don't mean generators. (Except when we do.) This confusion might partly reflect the somewhat confusing transition from 'yield from' to async/await, as demonstrated by the official doc's somewhat confusing definition of "coroutine": https://docs.python.org/3/library/asyncio-task.html#coroutine But going forward, yield-from-based coroutines and @asyncio.coroutine and all that are quickly becoming a historical curiosity, and most of the time what we really want to be talking about are just async functions. *So:* I'm not suggesting we modify Python itself to rename types.coroutine or the .cr_* fields or anything, that's all expert internal stuff (possible exception: the __repr__ for async functions). But I do propose that we all agree to do a search/replace for s/coroutine/async function/g on our end-user docs and when generally talking about these things, and announce that we're doing so. It's a small thing and a bit of work, but if there's a general agreement to do it in a coordinated way then I think it could be pretty straightforward transition that will pay dividends for a long time. -n -- Nathaniel J. Smith -- https://vorpus.org

5 10

Re: [Async-sig] [python-tulip] Python 3.6b2 will have C implemented Future
by Ben Darnell 19 Nov '16

19 Nov '16

[+async-sig(a)python.org <async-sig(a)python.org>, which is the new home for these kinds of discussions] Tornado's tests are now failing on nightly with "TypeError: can't send non-None value to a FutureIter": https://travis-ci.org/tornadoweb/tornado/jobs/167252979 -Ben On Tue, Oct 11, 2016 at 3:55 PM INADA Naoki <songofacandy(a)gmail.com> wrote: > > If you have asyncio based project, and it uses Travis-CI, > > > please add "nightly" to your .travis.cnf [2]. > > > > > > [2] > > > > https://docs.travis-ci.com/user/languages/python/#Choosing-Python-versions-… > > > > Travis changed the "nightly" version to 3.7 > > Now "3.6-dev" is for Python 3.6beta (Still 3.6b1, it may be upgraded soon). > > > > -- > > INADA Naoki <songofacandy(a)gmail.com> > >

4 8

sans io implementation
by MultiSosnooley . 08 Nov '16

08 Nov '16

Hi. I'm trying to make sans-io library. 1. Protocol works over http, so I've just passing Request object with method, url, data, etc. fields to user and receive Response object (json in this case). 2. I'm using generators for simplification of holding state of multirequest actions. Something like this: def login(): response = yield Request(...) # check server state # update state with response response = yield Request(...) # actually login yield None def act(generator): response = None while True: request = generator.send(response) if request is None: return response response = # do io act(login()) This solve problem multistep actions. The downside is that all your protocol functions, event if they have only one request and don't need response at all, must be generators. Is it ok to send just abstract Request and receive abstract Response (not just bytes)? Is there a better solution for multirequest actions?

2 2

Status of asyncio.readthedocs.io ?
by Ludovic Gasc 02 Nov '16

02 Nov '16

Hi everybody, For me, http://asyncio.readthedocs.io/ is enough stable now to promote the project. Ok for everybody, or you want to add content or change the structure ? BTW, thanks to all contributors, especially Victor Stinner and Mike Müller from Python-Academy: https://github.com/asyncio-doc/asyncio-doc/graphs/contributors Have a nice week. PS: No answer before Sunday = approved by people in the mailing-lists ;-) -- Ludovic Gasc (GMLudo) http://www.gmludo.eu/

1 1

Re: [Async-sig] [python-tulip] Python 3.6b2 will have C implemented Future
by INADA Naoki 15 Oct '16

15 Oct '16

Thank you for information. I'll look it, hopefully in next week. 2016/10/15 午前2:24 "Julien Duponchelle" <julien(a)gns3.net>: > On Sun, Oct 9, 2016 at 8:06 AM Naoki INADA <songofacandy(a)gmail.com> wrote: > >> Hi. >> >> I've just pushed C implementation of asyncio.Future [1]. >> It will be included in Python 3.6b2. >> >> It may have rough edge. But I hope it will be battle tested >> before Python 3.6.0. >> Please help us by running your tests on Python 3.6b2, and >> report issues you found. >> If you have asyncio based project, and it uses Travis-CI, >> please add "nightly" to your .travis.cnf [2]. >> >> Feedback about performance difference is also welcome. >> >> Thanks, >> >> [1]: https://hg.python.org/cpython/rev/678424183b38 >> [2] https://docs.travis-ci.com/user/languages/python/# >> Choosing-Python-versions-to-test-against >> > > Hi, > > I have setup a 3.6 build on Travis of our project GNS3 and it seem to fail. > https://travis-ci.org/GNS3/gns3-server/builds/167703118 > > To be honest I didn't dig the issue and could be wrong usage of asyncio > (or ugly mock in tests). But this could perhaps interest you. > > I think the most interresting test is: > https://travis-ci.org/GNS3/gns3-server/jobs/167702085#L2270 > > Because we test a websocket client server connection. > > Thanks a lot for your work >

1 0

Async-sig October 2016