[Python-Dev] PEP 492: async/await in Python; version 4

[Brett Cannon]

On Tue, May 5, 2015 at 3:14 PM Paul Moore <p.f.moore at gmail.com> wrote:

> On 5 May 2015 at 19:25, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> > On 2015-05-05 7:27 AM, Wolfgang wrote:
> >> Even the discussion on python-dev suggests there is some time needed
> >> to finalize all this.
> >
> > I'd say that:
> >
> > 80% of the recent discussion of the PEP is about terminology.
> > 10% is about whether we should have __future__ import or not.
>
> But the terminology discussion appears to revolve around people
> finding the various concepts involved in asyncio (particularly the new
> PEP, but also to an extent the existing implementation) confusing. I
> can confirm, having tried to work through the asyncio docs, that the
> underlying concepts and how they are explained, are confusing to an
> outsider.
>
> That's not to say that everything needs to be beginner-friendly, but
> it *does* mean that it's hard for the wider Python community to
> meaningfully comment, or evaluate or sanity-check the design. We're
> left with a sense of "trust us, it makes sense if you need it,
> everyone else can ignore it".
>

Watch David Beazley's talk from PyCon this year and you can watch him
basically re-implement asyncio on stage in under 45 minutes. It's not as
complicated as it seems when you realize there is an event loop driving
everything (which people have been leaving out of the conversation since it
doesn't tie into the syntax directly).


>
> Personally, I feel as if PEP 492 is looking a little premature - maybe
> the focus should be on making asyncio more accessible first, and
> *then* adding syntax.


I think this ties the concept of adding syntax to Python to make
coroutine-based programming easier too much to asyncio; the latter is just
an implementation of the former. This PEP doesn't require asyncio beyond
the fact that will be what provides the initial event loop in the stdlib.


> You can argue that the syntax is needed to help
> make async more accessible - but if that's the case then the
> terminology debates and confusion are clear evidence that it's not
> succeeding in that goal.


Perhaps, but arguing about the nitty-gritty details of something doesn't
automatically lead to a clearer understanding of the higher level concept.
Discussing how turning a steering wheel in a car might help you grasp how
cars turn, but it isn't a requirement to get "turn the wheel left to make
the car go left".


> Of course, that's based on my perception of
> one of the goals of the PEP as being "make coroutines and asyncio more
> accessible", If the actual goals are different, my conclusion is
> invalid.
>

I think the goal is "make coroutines easier to use" and does not directly
relate to asyncio.


>
> >> We forget to address the major problems here. How can someone in a
> >> "sync" script use this async stuff easy. How can async and sync stuff
> >> cooperate and we don't need to rewrite the world for async stuff.
> >> How can a normal user access the power of async stuff without rewriting
> >> all his code. So he can use a simple asyc request library in his code.
> >> How can a normal user learn and use all this in an easy way.
> >
> > asyncio and twisted answered these questions ;) The answer is
> > that you have to write async implementations.
>
> Well, twisted always had defer_to_thread. Asyncio has run_in_executor,
> but that seems to be callback-based rather than coroutine-based?
>

Yep.


>
> Many people use requests for their web access. There are good reasons
> for this. Are you saying that until someone steps up and writes an
> async implementation of requests, I have to make a choice - requests
> or asyncio?


I believe so; you need something to implement __await__. This is true in
any language that implements co-routines.

Unfortunately, I can't see myself choosing asyncio in that
> situation. Which again means that asyncio becomes "something that the
> average user can't use". Which in turn further entrenches it as a
> specialist-only tool.
>

You forgot to append "... yet" to that statement. Just because something
isn't available out of the box without some effort to support doesn't mean
it will never happen, else there would be absolutely no Python 3 users out
there.


>
> As another example, in Twisted I could use defer_to_thread to
> integrate Oracle database access into a twisted application (that's
> what the twisted database stuff did under the hood). Can I do that
> with asyncio? Will the syntax in the PEP help, hinder or be irrelevant
> to that?
>
> >> And for all this we still can't tell them "oh the async stuff solves
> >> the multiprocessing problem of Python learn it and switch to version
> >> 3.5". It does not and it is only most useful for networking stuff
> >> nothing more.
> >
> > "networking stuff", and in particular, web, is a huge
> > part of current Python usage.  Please don't underestimate
> > that.
>
> Without async versions of requests and similar, how much of a chunk of
> the networking/web area will asyncio take? (Genuine question, I have
> no idea). And how much extra will this PEP add? Those may not be fair
> questions (and even if they are fair, the answers are probably
> unknowable), but as an outsider, I feel only the costs of the asyncio
> implementation (a new library that I don't understand, and now a
> relatively large amount of new syntax and special methods I have to
> ignore because they don't make sense to me). That's OK, but I think I
> am being reasonable to ask for some sense of the level of benefits
> others are getting to balance out the costs I incur.
>

Co-routine-based asynchronous programming is new to Python, so as a
community we don't have it as something everyone learns over time. If you
don't come from an area that supports it then it will be foreign to you and
not make sense without someone giving you a good tutorial on it. But
considering C#, Dart, and Ecmascript 6 (will) have co-routine support --
and those are just the languages I can name off the top of my head -- using
the exact same keywords suggests to me that it isn't *that* difficult of a
topic to teach people. This is just one of those PEPs where you have to
trust the people with experience in the area are making good design
decisions for those of us who aren't in a position to contribute directly
without more experience in the domain.

-Brett


>
> Paul
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150505/b194e329/attachment-0001.html>