[Async-sig] Optional Asynchronous Interface

[James Stidard]

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 at python.org> <guido at python.org>
Reply: guido at python.org <guido at python.org> <guido at python.org>
Date: 29 September 2016 at 11:40:14 pm
To: James Stidard <jamesstidard at gmail.com> <jamesstidard at gmail.com>
Cc: async-sig at python.org <async-sig at python.org> <async-sig at 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 at 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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160929/fd005db5/attachment-0001.html>