From jamesstidard at gmail.com  Thu Sep 29 18:10:58 2016
From: jamesstidard at gmail.com (James Stidard)
Date: Thu, 29 Sep 2016 15:10:58 -0700
Subject: [Async-sig] Optional Asynchronous Interface
Message-ID: <CAPGcbrCm0eGHVO8bXSy8f1Yko7i-wiqdS1A-uOuUyixyvWoXOw@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160929/373d52b8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dual_interface.py
Type: application/octet-stream
Size: 1207 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160929/373d52b8/attachment.obj>

From guido at python.org  Thu Sep 29 18:39:53 2016
From: guido at python.org (Guido van Rossum)
Date: Thu, 29 Sep 2016 15:39:53 -0700
Subject: [Async-sig] Optional Asynchronous Interface
In-Reply-To: <CAPGcbrCm0eGHVO8bXSy8f1Yko7i-wiqdS1A-uOuUyixyvWoXOw@mail.gmail.com>
References: <CAPGcbrCm0eGHVO8bXSy8f1Yko7i-wiqdS1A-uOuUyixyvWoXOw@mail.gmail.com>
Message-ID: <CAP7+vJJ7AJcHpOi5GPUfkrd3mYOB9f0GLVWZ3mg7GMx5MUW=yA@mail.gmail.com>

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)

From jamesstidard at gmail.com  Thu Sep 29 19:15:36 2016
From: jamesstidard at gmail.com (James Stidard)
Date: Thu, 29 Sep 2016 16:15:36 -0700
Subject: [Async-sig] Optional Asynchronous Interface
In-Reply-To: <CAP7+vJJ7AJcHpOi5GPUfkrd3mYOB9f0GLVWZ3mg7GMx5MUW=yA@mail.gmail.com>
References: <CAPGcbrCm0eGHVO8bXSy8f1Yko7i-wiqdS1A-uOuUyixyvWoXOw@mail.gmail.com>
 <CAP7+vJJ7AJcHpOi5GPUfkrd3mYOB9f0GLVWZ3mg7GMx5MUW=yA@mail.gmail.com>
Message-ID: <CAPGcbrDn6CwTe3m6nC-oZrAgZcmJYmer2_vwBu4m0Mb6nX8iFA@mail.gmail.com>

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>

From guido at python.org  Thu Sep 29 19:18:48 2016
From: guido at python.org (Guido van Rossum)
Date: Thu, 29 Sep 2016 16:18:48 -0700
Subject: [Async-sig] Optional Asynchronous Interface
In-Reply-To: <CAPGcbrDn6CwTe3m6nC-oZrAgZcmJYmer2_vwBu4m0Mb6nX8iFA@mail.gmail.com>
References: <CAPGcbrCm0eGHVO8bXSy8f1Yko7i-wiqdS1A-uOuUyixyvWoXOw@mail.gmail.com>
 <CAP7+vJJ7AJcHpOi5GPUfkrd3mYOB9f0GLVWZ3mg7GMx5MUW=yA@mail.gmail.com>
 <CAPGcbrDn6CwTe3m6nC-oZrAgZcmJYmer2_vwBu4m0Mb6nX8iFA@mail.gmail.com>
Message-ID: <CAP7+vJK5Fx5BCVFFCgsDrU7_EcUVNbEsaYL1YXttSXLDw7u+Ow@mail.gmail.com>

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)

From jamesstidard at gmail.com  Thu Sep 29 19:25:42 2016
From: jamesstidard at gmail.com (James Stidard)
Date: Thu, 29 Sep 2016 16:25:42 -0700
Subject: [Async-sig] Optional Asynchronous Interface
In-Reply-To: <CAP7+vJK5Fx5BCVFFCgsDrU7_EcUVNbEsaYL1YXttSXLDw7u+Ow@mail.gmail.com>
References: <CAPGcbrCm0eGHVO8bXSy8f1Yko7i-wiqdS1A-uOuUyixyvWoXOw@mail.gmail.com>
 <CAP7+vJJ7AJcHpOi5GPUfkrd3mYOB9f0GLVWZ3mg7GMx5MUW=yA@mail.gmail.com>
 <CAPGcbrDn6CwTe3m6nC-oZrAgZcmJYmer2_vwBu4m0Mb6nX8iFA@mail.gmail.com>
 <CAP7+vJK5Fx5BCVFFCgsDrU7_EcUVNbEsaYL1YXttSXLDw7u+Ow@mail.gmail.com>
Message-ID: <CAPGcbrC8Aa_Gzy2Q_X0UNFcn9Jv5zbkT4da3Fp6mZmO4UCdETw@mail.gmail.com>

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>

From guido at python.org  Thu Sep 29 19:31:42 2016
From: guido at python.org (Guido van Rossum)
Date: Thu, 29 Sep 2016 16:31:42 -0700
Subject: [Async-sig] Optional Asynchronous Interface
In-Reply-To: <CAPGcbrC8Aa_Gzy2Q_X0UNFcn9Jv5zbkT4da3Fp6mZmO4UCdETw@mail.gmail.com>
References: <CAPGcbrCm0eGHVO8bXSy8f1Yko7i-wiqdS1A-uOuUyixyvWoXOw@mail.gmail.com>
 <CAP7+vJJ7AJcHpOi5GPUfkrd3mYOB9f0GLVWZ3mg7GMx5MUW=yA@mail.gmail.com>
 <CAPGcbrDn6CwTe3m6nC-oZrAgZcmJYmer2_vwBu4m0Mb6nX8iFA@mail.gmail.com>
 <CAP7+vJK5Fx5BCVFFCgsDrU7_EcUVNbEsaYL1YXttSXLDw7u+Ow@mail.gmail.com>
 <CAPGcbrC8Aa_Gzy2Q_X0UNFcn9Jv5zbkT4da3Fp6mZmO4UCdETw@mail.gmail.com>
Message-ID: <CAP7+vJJAB7P+TD_2EvHYe=v1Jr6Ca1bbz030OdS5Kpb8R1JoZg@mail.gmail.com>

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



-- 
--Guido van Rossum (python.org/~guido)

From jamesstidard at gmail.com  Thu Sep 29 19:40:20 2016
From: jamesstidard at gmail.com (James Stidard)
Date: Thu, 29 Sep 2016 16:40:20 -0700
Subject: [Async-sig] Optional Asynchronous Interface
In-Reply-To: <CAP7+vJJAB7P+TD_2EvHYe=v1Jr6Ca1bbz030OdS5Kpb8R1JoZg@mail.gmail.com>
References: <CAPGcbrCm0eGHVO8bXSy8f1Yko7i-wiqdS1A-uOuUyixyvWoXOw@mail.gmail.com>
 <CAP7+vJJ7AJcHpOi5GPUfkrd3mYOB9f0GLVWZ3mg7GMx5MUW=yA@mail.gmail.com>
 <CAPGcbrDn6CwTe3m6nC-oZrAgZcmJYmer2_vwBu4m0Mb6nX8iFA@mail.gmail.com>
 <CAP7+vJK5Fx5BCVFFCgsDrU7_EcUVNbEsaYL1YXttSXLDw7u+Ow@mail.gmail.com>
 <CAPGcbrC8Aa_Gzy2Q_X0UNFcn9Jv5zbkT4da3Fp6mZmO4UCdETw@mail.gmail.com>
 <CAP7+vJJAB7P+TD_2EvHYe=v1Jr6Ca1bbz030OdS5Kpb8R1JoZg@mail.gmail.com>
Message-ID: <CAPGcbrDugW9ydpKohJbNV5Z=tx2nJZSRK=NerYnCJFUBY8r6yg@mail.gmail.com>

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 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:32:02 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

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



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