[Python-Dev] Importance of "async" keyword

Steven D'Aprano steve at pearwood.info
Fri Jun 26 04:22:19 CEST 2015

On Thu, Jun 25, 2015 at 05:55:53PM +0200, Sven R. Kunze wrote:
> On 25.06.2015 04:16, Steven D'Aprano wrote:
> >On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
> >>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?

I think so. If you call a syncronous function when you want something 
asyncronous, or vice versa, you're going to be disappointed or confused 
by the result.

> ># 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.

Where would the function suspend if there are zero suspension points?

How can you tell what the suspension points *in* the coroutine are from 
"await func()"? 

> 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.

Concurrency is not classical single-processing programming.

> 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).

It might help if you give a concrete example. Can you show a code 
snippet of your proposal? A single function with zero suspension points 
being called both asyncronously and syncronously, where does it suspend? 
It doesn't need to be a big complex function, something simple will do.

> 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).

I expect that it will be simple to write a wrapper that converts an 
ayncronous function to a syncronous one. It's just a matter of waiting 
until it's done.


More information about the Python-Dev mailing list