[Python-Dev] Importance of "async" keyword

[Nick Coghlan]

On 27 June 2015 at 00:31, Chris Angelico <rosuav at gmail.com> wrote:
> I come from a background of thinking with threads, so I'm accustomed
> to doing blocking I/O and assuming/expecting that other threads will
> carry on while we wait. If asynchronous I/O can be made that
> convenient, it'd be awesome.

Folks, it's worth reading through both
https://glyph.twistedmatrix.com/2014/02/unyielding.html and
http://python-notes.curiousefficiency.org/en/latest/pep_ideas/async_programming.html

It *is* possible to make a language where *everything* is run as a
coroutine, and get rid of the subroutine/coroutine distinction that
way - a subroutine would *literally* be executed as a coroutine that
never waited for anything. The "doesn't suspend" case could then be
handled as an implicit optimisation, rather than as a distinct type,
and the *only* way to do IO would be asynchronously through an event
loop, rather than through blocking API calls.

But that language wouldn't be Python. Python's core execution model is
a synchronous procedural dynamically typed one, with everything beyond
that, whether object oriented programming, functional programming,
asynchronous programming, gradual typing, etc, being a way of managing
the kinds of complexity that arise when managing more state, or more
complicated algorithms, or more interactivity, or a larger development
team.

> But since it hasn't already been made that easy in every other
> language, I expect there's some fundamental problem with this
> approach, something that intrinsically requires every step in the
> chain to know what's a (potential) block point.

As Glyph explains, implicitly switched coroutines are just shared
memory threading under another name - when any function call can cause
you to lose control of the flow of execution, you have to consider
your locking model in much the same way as you do for preemptive
threading.

For Python 2, this "lightweight threads" model is available as
https://pypi.python.org/pypi/gevent, and there also appears to have
been some good recent progress on Python 3 compatibility:
https://github.com/gevent/gevent/issues/38

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia