On 27 June 2015 at 00:31, Chris Angelico <rosuav@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_programm... 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@gmail.com | Brisbane, Australia