[Async-sig] Optional Asynchronous Interface

[James Stidard]

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 at python.org> <guido at python.org>
Reply: guido at python.org <guido at python.org> <guido at python.org>
Date: 30 September 2016 at 12:19:08 am
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

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 at 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 at python.org>
> Reply: guido at python.org <guido at python.org>
> Date: 29 September 2016 at 11:40:14 pm
> To: James Stidard <jamesstidard at gmail.com>
> Cc: 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)



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160929/becb318e/attachment.html>