On 11 Aug 2016 18:48, "Cory Benfield" <[email protected]> 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.
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
