[Python-ideas] Are there asynchronous generators?

Paul Moore p.f.moore at gmail.com
Thu Jul 2 11:57:40 CEST 2015

On 1 July 2015 at 06:56, Nick Coghlan <ncoghlan at gmail.com> wrote:
> For folks that primarily deal with algorithmic problems where inputs
> are converted to outputs, the event driven model addresses a kind of
> problem that *they don't have*, so it can seem entirely pointless.
> However, there really are significant categories of problems (such as
> network service development) where the event driven model is a
> genuinely superior design tool. Like array oriented programming (and
> even object-oriented and functional programming), the benefits can
> unfortunately be hard to explain to folks that haven't personally
> experienced the problems these tools address, so folks end up having
> to take it on faith that we're applying the "Complex is better than
> complicated" line from the Zen of Python when introducing new
> modelling techniques into the core language.

Hmm, I see what you're getting at here, but my "event driven model"
background is with GUI event loops, not with event driven IO. The
async/await approach still gives me problems, because I can't map the
details of the approach onto the problem domain I'm familiar with.

What I can't quite work out is whether that's simply because asyncio
is fundamentally designed around the IO problem (the module name
suggests that might be the case, but a lot of the module content
around tasks, etc, doesn't seem to be), and so doesn't offer any sort
of mental model for understanding how GUI event loop code based on
async/await would work, or if it's because the async/await design
genuinely doesn't map well onto GUI event loop problems.

I've been poking in the background at trying to decouple the "IO"
aspects of asyncio from the "general" ones, but honestly, I'm not
getting very far yet. I think what I need to do is to work out how to
write a GUI event loop that drives async/await style coroutines, and
see if that helps me understand the model better. But there aren't
many examples of event loops around to work from (the asyncio one is
pretty complex, and it's hard to know how much of that complexity is
needed, and how much is because it was developed before async/await
were available).

So while I agree that if you don't need an event driven model, it can
seem like pointless complexity, I *also* think that the pure callback
approach to event driven code is what feels "obvious" to most people.
It's maybe not the easiest model to code with, but it is the easiest
one to think about - and mentally making the link between callbacks
and async/await isn't straightforward. So even though people can
understand event-driven problems, they can't, without experience, see
how async/await *addresses* that problem.


More information about the Python-ideas mailing list