[Python-ideas] Are there asynchronous generators?

[Andrew Barnert]

One way for a GUI developer to get the hang of the point of asyncio is to imagine this problem:

I've written a synchronous, modal, menu-driven app. I want to turn that into a GUI app, maybe using a wizard-like design, with a pane for each menu. To do that, I basically have to turn my control-flow inside-out. But if, at each step, I could just put up the next pane and "await" the user's response, my code would look much the same as the original CLI code. And if I wanted to let the user fire off multiple "wizards" in parallel (an MDI interface, treating each one as a document), it would just work, because each wizard is a separate coroutine that spends most of its time blocked on the event loop.

The difference between a server and an MDI app is that you usually need hundreds or thousands of connections as opposed to a handful of documents, but the control flow for each is usually more linear, so the wizard-like design is a much more obvious choice.

> On Jul 2, 2015, at 02:57, Paul Moore <p.f.moore at gmail.com> wrote:
> 
>> 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.
> 
> Paul
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/