[Python-ideas] PEP 525: Asynchronous Generators

[Nick Coghlan]

On 11 Aug 2016 18:48, "Cory Benfield" <cory at lukasa.co.uk> wrote:
>
> While we’re talking about function colour, we should note that you don’t
*have* to have function colour. A quick look at your average Twisted
codebase that doesn’t use @inlineCallbacks will quickly show you that you
can write an asynchronous program using nothing but synchronous function
calls, so long as you are careful. And this has always been true: in my
first job I worked on a cooperative-multitasking program written entirely
in C, and as we all know C has absolutely no method for describing function
colour. Again, so long as you are careful and don’t do any blocking I/O in
your program, everything works just fine.

Twisted callbacks are still red functions - you call them via the event
loop rather than directly, and only event loop aware functions know how to
make that request of the event loop.

async/await just makes the function colour locally visible with a clear
syntax, rather than needing to be inferred from behavioural details of the
function implementation.

> The general long term solution to this is not to remove function colour,
because it helps people. The long term solution is to develop a programming
culture that says that 99% of your code should be normal functions, and
only the last tiny 1% should make any statements about function colour.
This is part of what the Sans-I/O project is about: demonstrating that you
should avoid painting your functions as async until the last possible
second, and that the fewer times you write
async/await/@asyncio.coroutine/yield from the easier your life gets.

This part I wholeheartedly agree with, though - the vast majority of code
will ideally be synchronous *non-blocking* code, suitable for use in data
transformation pipelines and other data modelling and manipulation
operations.

Similar to Unicode handling, "event-driven or blocking?" is a decision best
made at *system boundaries*, with the bulk of the application code not
needing to worry about that decision either way.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160811/e3e1bd70/attachment-0001.html>