Well, you can do anything with a decorator. :-) I was actually trying to gently steer you away from this pattern. Just because it can be made to work doesn't mean it's a good idea.
On Thu, Sep 29, 2016 at 4:15 PM, James Stidard <jamesstid...@gmail.com> wrote: > 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> > Reply: gu...@python.org <gu...@python.org> > Date: 29 September 2016 at 11:40:14 pm > To: James Stidard <jamesstid...@gmail.com> > Cc: 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) -- --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/
