Yeah that’s true - that’s a less convoluted way. It would also mean you aren’t stealing a kwarg from the function.
Though, it does stop you requiring an import everywhere you’d use one of the libraries functions and, for my eyes, makes it a little nicer to read. You could also set a environment variable to say 'I want to use async or sync by default throughout the application' - then the wrapper could use that. I’m glad that I’m not going mad though and nothing is glaring wrong to you - I feel you’re a pretty reputable when it comes to python. I seem to remember reading something that implied you’d have to maintain two different functions because you couldn’t call a async def from a def. Thanks for the quick reply, James From: Guido van Rossum <gu...@python.org> <gu...@python.org> Reply: gu...@python.org <gu...@python.org> <gu...@python.org> Date: 29 September 2016 at 11:40:14 pm To: James Stidard <jamesstid...@gmail.com> <jamesstid...@gmail.com> Cc: async-sig@python.org <async-sig@python.org> <async-sig@python.org> Subject: Re: [Async-sig] Optional Asynchronous Interface Interesting, but wouldn't it be simpler to provide a helper so that you can write result = wait(my_function()) for the synchronous version and result = await my_function() for the async version? On Thu, Sep 29, 2016 at 3:10 PM, James Stidard <jamesstid...@gmail.com> wrote: > 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 > > _______________________________________________ > Async-sig mailing list > Async-sig@python.org > https://mail.python.org/mailman/listinfo/async-sig > Code of Conduct: https://www.python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
