Mailman 3 - Async-sig

async/sync library reusage
by manuel miranda June 12, 2017

June 12, 2017

Hello everyone, After using asyncio for a while, I'm struggling to find information about how to support both synchronous and asynchronous use cases for the same library. I.e. imagine you have a package for http requests and you want to give the user the choice to use a synchronous or an asynchronous interface. Right now the approach the community is following is creating separate libraries one for each version. This is far from ideal for several reasons, some I can think of: - Code … [View More]

10 28

PyCon US 2017 open space on Saturday sometime after lunch
by Brett Cannon May 20, 2017

May 20, 2017

I have not picked a time yet and I can't book it until tomorrow, but the plan is sometime after lunch on Saturday I will book an async open space.

4 4

[ann] sphinxcontrib-trio: make sphinx better at documenting functions/methods, esp. for async/await code
by Nathaniel Smith May 13, 2017

May 13, 2017

Hi all, I just released a new package, sphinxcontrib-trio: https://sphinxcontrib-trio.readthedocs.io/ It makes it easier to document many kinds of functions/methods in sphinx, including async functions, abstract methods, generators, etc. I originally wrote it for the trio [1] project, hence the name, but don't let that put you off -- there's nothing about it that's specific to trio, or even to async/await (except that projects that use async/await *really need* an extension like this). … [View More]

3 5

Control-C handling in Python and Trio
by Nathaniel Smith April 23, 2017

April 23, 2017

Hi async-sig, Some of you have probably already seen this, but in case it's of interest, I just posted some discussion of signal handling and how I approach it in trio: https://vorpus.org/blog/control-c-handling-in-python-and-trio/ If nothing else at least it's the signal handling documentation that I wish I had when I started :-). -n -- Nathaniel J. Smith -- https://vorpus.org

3 2

Trio: async I/O for humans and snake people
by Nathaniel Smith March 16, 2017

March 16, 2017

Hi all, I'd like to announce the initial release of Trio, a new permissively-licensed async I/O library for Python 3.5+. Blog post with more details: https://vorpus.org/blog/announcing-trio/ Or you can jump straight to the repo: https://github.com/python-trio/trio/ Cheers, -n -- Nathaniel J. Smith -- https://vorpus.org

2 2

Debugging destroyed, pending tasks
by Mark E. Haase Feb. 2, 2017

Feb. 2, 2017

I'm still climbing up the asyncio learning curve. I'm building an application on top of asyncio, and one of my goals is that when the application is interrupted (e.g. SIGINT), it should carefully clean up all running tasks before closing the event loop. Some tasks should be cancelled right away, but other tasks should be allowed to complete. As an example of the latter, I may have several file download tasks that I want to finish before closing the event loop. (If I get a 2nd SIGINT, then I … [View More]

2 2

Re: [Async-sig] Some thoughts on asynchronous API design in a post-async/await world
by Dima Tisnek Feb. 2, 2017

Feb. 2, 2017

Hi list, sorry for being a bit late, but I only discovered that post recently... I've a couple concerns: 1. update now 3.6 is out, the post should be rewritten or new one made, mainly because this post if what inquisitive minds find... 2. asyncio for whom? I've presented asyncio tutorial of sourts at a local Python meetup. I've noticed that asyncio documentation is pretty hard to understand. There are many concepts and a ton of caveats. I now finally understand why, and I think it comes … [View More]

1 0

A modest terminological proposal
by Nathaniel Smith Dec. 28, 2016

Dec. 28, 2016

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 … [View More]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 [View Less]

5 10

Re: [Async-sig] A modest terminological proposal
by Thomas Nyberg Nov. 30, 2016

Nov. 30, 2016

This is in reply to this message in the archives: https://mail.python.org/pipermail/async-sig/2016-October/000141.html Nathaniel Smith: > 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. For … [View More]what it's worth, I 100% agree. > *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": I've personally been very confused lately by python's terminology. I've always understood coroutines to have nothing a priori to do with event loops, scheduling. For example, I've understood coroutines as being objects that allow the following kind of flow (taken from https://en.wikipedia.org/wiki/Coroutine#Comparison_with_subroutines): var q := new queue coroutine produce loop while q is not full create some new items add the items to q yield to consume coroutine consume loop while q is not empty remove some items from q use the items yield to produce Python has basically supported this flow since 2.x (apart from the terminology issue of semi-coroutines mentioned above which I feel is relatively minor). This big point though is that being scheduled or asyncronous is kind of a separate property. Posix threads are implemented by feeding it a routine to start things off just like much of python's asyncronous stuff is built around coroutines, but I don't feel like the term "coroutines" should be merged into both just as routines aren't automatically tied to threads. Personally I think if anything the best possible comparison else where in computer science are the haskell thunks which delay execution until needed. That's the first thing I think about when I see how curio is setup for example. I recognize that it is very unlikely that this will change (hey language meaning changes over time), but I felt like I should reply after finding this thread because I personally have been very confused by the terminology used by python. (Personally I've been using coroutines by my definition for years using yield/send.) Thanks a lot for the write-up though. You saved my sanity a little bit... Cheers, Thomas [View Less]

2 1

[ANN] async_generator v1.2 released
by Nathaniel Smith Nov. 26, 2016

Nov. 26, 2016

Hi all, I just released v1.2 of my async_generator package: https://pypi.org/pypi/async_generator/ This package makes it easy to write PEP 525-style "async generators", even on Python 3.5. It looks like: from async_generator import async_generator, yield_, yield_from_ @async_generator async def parse_json_separated_newlines_from_network(streamreader): async for line in streamreader: await yield_(json.loads(line)) Starting in v1.1 (released last week but … [View More]

2 16