[Python-Dev] Importance of "async" keyword

[Sven R. Kunze]

On 25.06.2015 04:16, Steven D'Aprano wrote:
> On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
>> Thanks, Yury, for you quick response.
>>
>> On 24.06.2015 22:16, Yury Selivanov wrote:
>>> Sven, if we don't have 'async def', and instead say that "a function
>>> is a *coroutine function* when it has at least one 'await'
>>> expression", then when you refactor "useful()" by removing the "await"
>> >from it, it stops being a *coroutine function*, which means that it
>>> won't return an *awaitable* anymore.  Hence the "await useful()" call
>>> in the "important()" function will be broken.
>> I feared you would say that. Your reasoning assumes that *await* needs
>> an *explicitly declared awaitable*.
>>
>> Let us assume for a moment, we had no async keyword. So, any awaitable
>> needs to have at least 1 await in it. Why can we not have awaitables
>> with 0 awaits in them?
> I haven't been following the async discussion in detail, but I would
> expect that the answer is for the same reason that you cannot have a
> generator function with 0 yields in it.
Exactly. That is why I do not stop here.
>
>>> 'async def' guarantees that function always return a "coroutine"; it
>>> eliminates the need of using @asyncio.coroutine decorator (or
>>> similar), which besides making code easier to read, also improves the
>>> performance.  Not to mention new 'async for' and 'async with' statements.
>> Recently, I read Guido's blog about the history of Python and how he
>> eliminated special cases from Python step by step. As I see it, the same
>> could be done here.
>>
>> What is the difference of a function (no awaits) or an awaitable (> 1
>> awaits) from an end-user's perspective (i.e. the programmer)?
> The first is syncronous, the second is asyncronous.
Correct. Main questions to me here: do I, as a caller, need to care?
>
>> My answer would be: none. When used the same way, they should behave in
>> the same manner. As long as, we get our nice tracebacks when something
>> went wrong, everything seems find to me.
> How is that possible?
>
> def func():
>      # Simulate a time consuming calculation.
>      time.sleep(10000)
>      return 42
>
> # Call func syncronously, blocking until the calculation is done:
> x = func()
> # Call func asyncronously, without blocking:
> y = func()
>
>
> I think that one of us is missing something here. As I said, I haven't
> followed the whole discussion, so it might be me. But on face value, I
> don't think what you say is reasonable.

Ah, wait. That is not what I intended and I completely agree with Guido 
when he says:
"I want to be able to *syntactically* tell where the suspension points 
are in coroutines." http://code.activestate.com/lists/python-dev/135906/

So, it is either:

# Call func syncronously, blocking until the calculation is done:
x = func()

# Call func asyncronously, without blocking:
y = await func()

So, from my perspective, no matter, how many (even zero) suspension 
points there are in func(), the first variant would still be blocking 
and the second one not.

Many programmers (when adhering to classical programming) conceive the 
world as if they call a function and simply do not care about how it 
works and what it does. The main thing is, it does what it is supposed 
to do.

Whether this function achieves the goal by working asynchronously or 
blocking, AND if I, as a programmer, allow the function to work 
asynchronously, is a completely different matter. That in turn is 
extremely well reflected by the 'await' keyword (IMHO at least).



Another issue that bothers me, is code reuse. Independent from whether 
the 'async def' makes sense or not, it would not allow us to reuse 
asyncio functions as if they were normal functions and vice versa (if I 
understood that correctly). So, we would have to implement things twice 
for the asyncio world and the classic world. To me, it would be 
important to use one function in either world where it suits me better. 
I am uncertain if that makes sense but right now it does to me.


One last thing regarding 'async def', that came to my mind recently, is 
that it compares to that necessity of Java to decorate functions with 
all possible exceptions that could be raised inside. Thankfully, we do 
not need to do that in Python. IIRC, it is considered bad practice as it 
ties modules together tighter as they need to be. If I add a single 
exception down in the traceback, I need to re-add it everywhere where 
that function is used. That is a mess regarding clean code. Somehow, 
'async def' reminds me of that, too, but maybe, I am missing something here.
>>> P.S. This and many other things were discussed at length on the
>>> mailing lists, I suggest you to browse through the archives.
>> I can imagine that. As said I went through of some of them, but it could
>> be that I missed some of them as well.
>>
>> Is there a way to search them through (by not using Google)?
> You can download the mailing list archive for the relevant months, and
> use your mail client to search them.

Thanks Steven. I already found one on the Web: 
http://code.activestate.com/lists/python-dev/

And as it seems, I already read through all relevant discussions. :-/