Optional Asynchronous Interface
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
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)
Hi,
I just joined this mailing list, but not overly sure if it’s the right
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
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
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 <guido@python.org> <guido@python.org> Reply: guido@python.org <guido@python.org> <guido@python.org> Date: 29 September 2016 at 11:40:14 pm 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 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: place library 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)
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:
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 <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)
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)
Code smell -- being able to call the same function both asynchronously and synchronously is highly surprising. Also it violates the rule of thumb that the value of an argument shouldn't affect the return type. On Thu, Sep 29, 2016 at 4:25 PM, James Stidard <jamesstidard@gmail.com> wrote:
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> Reply: guido@python.org <guido@python.org> Date: 30 September 2016 at 12:19:08 am
To: James Stidard <jamesstidard@gmail.com> Cc: 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:
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 <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)
-- --Guido van Rossum (python.org/~guido)
Perfect, exactly what I was after. It was fun to solve anyway, even if I’m nothing to use it. I’ll stop taking advantage of your time now :) Thank you. 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:32:02 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 Code smell -- being able to call the same function both asynchronously and synchronously is highly surprising. Also it violates the rule of thumb that the value of an argument shouldn't affect the return type. On Thu, Sep 29, 2016 at 4:25 PM, James Stidard <jamesstidard@gmail.com> wrote:
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> Reply: guido@python.org <guido@python.org> Date: 30 September 2016 at 12:19:08 am
To: James Stidard <jamesstidard@gmail.com> Cc: 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:
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 <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)
-- --Guido van Rossum (python.org/~guido)
participants (2)
-
Guido van Rossum -
James Stidard