Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Ian Kelly <ian.g.kelly@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: How the heck does async/await work in Python 3.5
Date: Sat, 20 Feb 2016 00:48:31 -0700
Lines: 45
Message-ID: <mailman.13.1455954554.13884.python-list@python.org>
References: <mailman.224.1455746935.22075.python-list@python.org> <56c7d145$0$1597$c3e8da3$5496439d@news.astraweb.com> <9d968a2e-f23c-4c93-979d-43dfa610c343@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <9d968a2e-f23c-4c93-979d-43dfa610c343@googlegroups.com>
Precedence: list
Xref: csiph.com comp.lang.python:103244

On Fri, Feb 19, 2016 at 10:24 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Less snarkily looks like a series of bolt-ons after bolt-ons
>
> IMHO Guido's (otherwise) uncannily sound intuitions have been wrong right from
> 2001 when he overloaded def for generators.
> And after that its been slippery-slope down: reusing generator-yield (statement)
> for coroutine-yield (expression)
> Most recently choosing these async-await keywords instead of the more symmetric
> suggestions of Greg Ewing

Two out of three of those are fine. IMO generators should have
required a separate keyword to distinguish them from ordinary
functions, but it's a minor complaint and they're otherwise a great
addition to the language.

I do think it's pretty clear at this point though that PEP 342 was a
mistake. We should never have introduced generator-based coroutines;
it's an abstraction with too much leakage. It doesn't make sense that
generator-based coroutines implement the iterator protocol, because
there's no reason to ever try to iterate over them. It also doesn't
make sense to ever iterate over a Future, and yet asyncio Futures,
which aren't even coroutines, are nevertheless *forced* to be iterable
just because that's how coroutines work. Otherwise you couldn't "yield
from" a Future.

As another point that happens to be fresh in my mind, awaiting a
Future on which an exception gets set is supposed to propagate the
exception. I recently found that this breaks if the exception in
question happens to be StopIteration (granted not one that should
generally be allowed to propagate anyway, but that's a separate
discussion) for the simple reason that raising StopIteration in a
generator is equivalent to returning None. The awaiting coroutine thus
gets a non-exceptional result of None rather than the expected
exception. The irritating thing to me is that this even plagues PEP
492 coroutines using "await" rather than "yield from", because the two
are basically the same under the covers. The former gets an iterator
by calling __await__ instead of __iter__, but it's still implemented
using an iterator. If you look at the asyncio.Future implementation,
__await__ is actually just a synonym of the __iter__ method.

My hope is that someday we can get rid of PEP 342 coroutines entirely.
Then maybe we can get a coroutine implementation that's actually sane.
PEP 492 with async/await and non-iterable semantics is a step in the
right direction, but ultimately I think we also need an underlying
implementation that *isn't* fundamentally based on iteration.