Mailman 3 - Async-sig

A tasks list and run every element again when finish
by David Pineda 25 Nov '16

25 Nov '16

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 with socket and communication methods. I ve tried with multiprocess but the broke because are different loop events. Yes, i tryyo mix asyncio with multiprocess, but in this case didn't work I will be very thankfull of you. Best Regards! -- David A. Pineda Osorio F:+56 9 82142267 Ingeniero Civil Electricista Universidad de Chile

1 1

aiostream release
by Vincent Michel 21 Nov '16

21 Nov '16

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 provides a couple of examples: http://pythonhosted.org/aiostream/examples.html Cheers, /Vincent

1 0

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

Adding asyncio.run() function in Python 3.6
by Yury Selivanov 18 Nov '16

18 Nov '16

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() 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

4 4

Some thoughts on asynchronous API design in a post-async/await world
by Nathaniel Smith 10 Nov '16

10 Nov '16

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 . 07 Nov '16

07 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

async contextmanager
by Federico Marani 01 Nov '16

01 Nov '16

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 14 Oct '16

14 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

Optional Asynchronous Interface
by James Stidard 29 Sep '16

29 Sep '16

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 implementations of essentially the same functions (one with awaits and ones without); I just wanted to run the async function on pythons current loop. I also wanted to present the interface in a consistent way without the need to prefix or suffix ‘async’ into the function name. e.g. result = my_function(asynchronous=False) result = await my_function(asynchronous=True) I didn’t think this would be possible but I think I managed it. I just want to sanity check this because I think it’s pretty cool if it works. I’ve attached the code I wrote to test it. The assumption I’ve made is about get_event_loop making sense for just picking the current python thread of execution. Any thoughts? If attachments aren’t supported, here’s a gist: https://gist.github.com/JamesStidard/3317969472f4b3fc938a4ab29c5e1ecf Thanks, James

2 6