Mailman 3 - Async-sig

A tasks list and run every element again when finish
by David Pineda Nov. 25, 2016

Nov. 25, 2016

Hello. I'm using the asyncio module. I have a list with different task, every tasks has different time to be done. In a figure: fn 1 -> -> -> -> fn 2 --> --> --> --> --> . . . fn N -----> -----> -----> -----> So i need to repeat every task when its done. I tried to use 'while' but while have to complete all list first to repeat the list, this is not useful for me. Y ask you, fellows, about if there are a way to do that. In particular these tasks are … [View More]

1 1

aiostream release
by Vincent Michel Nov. 21, 2016

Nov. 21, 2016

Hi all, I just released aiostream, a collection of generator-based operators for asynchronous iteration. - GitHub: https://github.com/vxgmichel/aiostream - PyPI: https://pypi.org/project/aiostream - Docs: http://pythonhosted.org/aiostream It can be seen as an asynchronous version of itertools, although some aspects are slightly different. The stream operators rely heavily on asynchronous generators (PEP 525), so python 3.6 is required. The project is fully tested, and the documentation … [View More]

1 0

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

Nov. 19, 2016

[+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]. > &… [View More]

4 8

Adding asyncio.run() function in Python 3.6
by Yury Selivanov Nov. 18, 2016

Nov. 18, 2016

One of the remaining problems with the event loop in asyncio is bootstrapping/finalizing asyncio programs. Currently, there are two different scenarios: [1] Running a coroutine: async def main(): # your program loop = asyncio.get_event_loop() try: loop.run_until_complete(main()) finally: loop.close() [2] Running a server: loop = asyncio.get_event_loop() srv = loop.run_until_complete( loop.create_server(…)) try: loop.run_forever(… [View More]) finally: try: srv.close() loop.run_until_complete(srv.wait_closed()) finally: loop.close() Both cases are *incomplete*: they don’t do correct finalization of asynchronous generators. To do that we’ll need to add another 1-3 lines of code (extra try-finally). This manual approach is really painful: * It makes bootstrapping asyncio code unnecessarily hard. * It makes the documentation hard to follow. And we can’t restructure the docs to cover the loop only in the advanced section. * Most of the people will never know about `loop.shutdown_asyncgen` coroutine. * We don’t have a place to add debug code to let people know that their asyncio program didn’t clean all resources properly (a lot of unordered warnings will be spit out instead). In https://github.com/python/asyncio/pull/465 I propose to add a new function to asyncio in Python 3.6: asyncio.run(). The function can either accept a coroutine, which solves [1]: async def main(): # your program asyncio.run(main()) Or it can accept an asynchronous generator, which solves [2]: async def main(): srv = await loop.create_server(…)) try: yield # let the loop run forever finally: srv.close() await srv.wait_closed() asyncio.run(main()) asyncio.run() solves the following: * An easy way to start an asyncio program that properly takes care of loop instantiation and finalization. * It looks much better in the docs. With asyncio.run people don’t need to care about the loop at all, most probably will never use it. * Easier to experiment with asyncio in REPL. * The loop and asynchronous generators will be cleaned up properly. * We can add robust debug output to the function, listing the unclosed tasks, servers, connections, asynchronous generators etc, helping people with the cleanup logic. * Later, if we need to add more cleanup code to asyncio, we will have a function to add the logic to. I feel that we should add this to asyncio. One of the arguments against that, is that overloading asyncio.run to accept both coroutines and asynchronous generators makes the API more complex. If that’s really the case, we can add two functions: asyncio.run(coro) and asyncio.run_forever(async_generator). Also take a look at https://github.com/python/asyncio/pull/465. Thanks, Yury [View Less]

4 4

Some thoughts on asynchronous API design in a post-async/await world
by Nathaniel Smith Nov. 10, 2016

Nov. 10, 2016

I just posted a long blog/essay that's probably of interest to folks here: https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-… The short version: I think curio something important to teach us; I tried to figure out what that is and how we can learn from it. -n -- Nathaniel J. Smith -- https://vorpus.org

9 22

sans io implementation
by MultiSosnooley . Nov. 7, 2016

Nov. 7, 2016

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

2 2

Status of asyncio.readthedocs.io ?
by Ludovic Gasc Nov. 2, 2016

Nov. 2, 2016

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

async contextmanager
by Federico Marani Nov. 1, 2016

Nov. 1, 2016

Has anyone tried to build an asynchronous version of @contextmanager? Is it even possible... given the use of yield?

4 3

Re: [Async-sig] [python-tulip] Python 3.6b2 will have C implemented Future
by INADA Naoki Oct. 14, 2016

Oct. 14, 2016

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

1 0

Optional Asynchronous Interface
by James Stidard Sept. 29, 2016

Sept. 29, 2016

Hi, I just joined this mailing list, but not overly sure if it’s the right place for this discussion or now - please tell me to quite down and go away if so :). But if you’d be so kind as to point me in the right direction that would also be good. I’m currently building a library which has an asynchronous interface and I wanted to make it also be callable serially - handy for users of the library not using coroutines, as well as just using in the REPL. I didn’t want to maintain two … [View More]

2 6