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
Haha clearly too gentle. That’s a shame, I’ll let the high from solving it fade and reconsider it :) Are you able to give me a anything specifically bad with it, or is it more of a ‘code smell’ kinda thing from your experience? From: Guido van Rossum <guido@python.org> <guido@python.org> Reply: guido@python.org <guido@python.org> <guido@python.org> Date: 30 September 2016 at 12:19:08 am To: James Stidard <jamesstidard@gmail.com> <jamesstidard@gmail.com> Cc: async-sig@python.org <async-sig@python.org> <async-sig@python.org> Subject: Re: [Async-sig] Optional Asynchronous Interface 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 <jamesstidard@gmail.com> wrote: 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 <guido@python.org> Reply: guido@python.org <guido@python.org> Date: 29 September 2016 at 11:40:14 pm To: James Stidard <jamesstidard@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 <jamesstidard@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)