Anyone know when most of the python stdlib (the batteries included part) will start itself using async/await (for any/all things that could block)?? I suppose it will never change due to backwards compat. (which feels odd...)?
Most code doesn't need to be non blocking. We only hear so much about non blocking because the Web is the big thing and Web programming benefits from it.
But there are hundreds of other fields in programming where IO is not the main issue, and hence don't need the additional complexity of being async.
Granted, asyncio does a good job at making async easier, but imperative code will always be easier to use, learn and teach. These qualities are very important, and made Python famous : easy to grow with, and yet powerful.
So the stdlib will remain as-is, the useful, easy and beautiful thing it has been.
We may see additions made to it so you can ALSO, when needed, do more stuff async. But really, I think we will see more and more external lib just doing that, so for when you DO need async, you will just pip install.
Things I do hope will have an additional async API though:
- urllib;
- sqlite3;
- subprocess.Synchronization would be a nightmare, but I think it would be a fun exercise to see what you could do in that framework.
The nice thing about this approach is that you can emulate blocking or non-blocking I/O within the same function or even against the same file descriptor. And processes are so cheap that if your callees do block in unexpected ways you can just move that one call into its own process that just sends you a message when it's done.
You don't get what you would normally think of as "while loops" though, which makes sense if you think about it.
I think the idea most similar to what the grandparent wants is instruction-level dataflow, where programs are DAGs, and instructions are only run when their inputs are ready, rather than when a program counter reaches them.
Physical dataflow machines were built that did this in hardware.
At a low level, that's exactly what modern CPUs do.
http://docs.openstack.org/developer/taskflow/
https://pypi.python.org/pypi/taskflow
And yes u can do things like built equation solvers to:
http://docs.openstack.org/developer/taskflow/examples.html#l...
And other neat things:
Still, it's possible to write blocking/nonblocking bridges for that stuff
Adding an event loop to an environment where there previously has not been one is non-trivial.
Also, changing existing blocking methods to be non-blocking would break everything that uses (and expects) those APIs to be blocking.
* File IO (`open()`) will remain blocking because there's no practical way to implement it in asyncio. This isn't Python's fault, the OS support is a mess. * Async Socket IO is already implemented in the stdlib. * The stdlib HTTP (urllib, urllib2) is pretty awful and I don't know of anybody who uses it, instead they opt for Requests. aiohttp is the asyncio equivalent of Requests. * SMTP would be nice to see async. * SQLite relies on file IO, so is likewise doomed to always block.
I can't think of anything else in the stdlib that is IO-driven.
Edit: sametmax mentioned subprocess, which I had overlooked. That would be a nice one to see.