Home Original page

[Python-Dev] Importance of "async" keyword

Greg Ewing greg.ewing at canterbury.ac.nz
Fri Jun 26 00:02:59 CEST 2015 
Sven R. Kunze wrote:

> # Call func syncronously, blocking until the calculation is done:
> x = func()
> 
> # Call func asyncronously, without blocking:
> y = await func()

Using the word "blocking" this way is potentially
confusing. The calling task is *always* blocked until
the operation completes. The difference lies in
whether *other* tasks are blocked or not.

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

You understand correctly. If the function is declared async,
you must call it with await; if not, you must not. That's not
ideal, but it's an unavoidable consequence of the way async/await
are implemented.

> So, we would have to implement things twice 
> for the asyncio world and the classic world.

Not exactly; it's possible to create a wrapper that takes an
async function and runs it to completion, allowing it to be
called from sync code. I can't remember offhand, but there's
likely something like this already in asyncio.

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

It's a similar situation, but nowhere near as severe. There
are only two possibilities, async or not. Once you've converted
a function to async, you won't need to change it again on
that score.

-- 
Greg
More information about the Python-Dev mailing list