[Python-Dev] Importance of "async" keyword
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
> 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