5 ms·

I absolutely love async Python. It lets me do stuff that would be hard with ordinary Python. No doubt it takes some effort and practice to grasp, but once you

I absolutely love async Python. It lets me do stuff that would be hard with ordinary Python. No doubt it takes some effort and practice to grasp, but once you have it worked out you'll find it's a powerful tool in the toolbelt. Many languages now have async and await - it's not exclusive to Python. The reason so many languages have gopne this way is that so far it's the easiest and most sensible solution to writing concurrent code in a way that won't become incomprehensible. And if you are trying to get your head around it, the easiest analogy is the web browser and JavaScript. If you have grasped JavaScript and the event loop then essentially you have grasped async Python, or not far from it. Some people misunderstand async Python - they think the point is to make Python faster - it isn't. The point is to enable concurrent programming. I do understand the haters - at first, until you grasp it, async Python so incredibly foreign and so different from ordinary synchronous Python that you might think "AAAARGH why did they do this and make it so hard"? But really it's not hard once you grasp the mental model of what is going on.

nurettin 6y ago
I had so much trouble getting the python tcp client to work like I wanted it to. Then I tried my hand on the async tcp client and was pleasantly surprised how simple it was. reader, writer = await asyncio.wait_for(asyncio.open_connection(), connect_timeout) line = "" while True: line = await asyncio.wait_for(reader.readline(), read_timeout) if line == b"": break yield line
- andrewstuart 6y ago
  I've written a bunch of things that were really well suited to async Python including an mpjeg server, a queueing server and a process management server that monitors the stdout and stderr of various processes and reads them in real time and acts upon the messages it reads. Each one of those applications was made possible comprehensible and even easy by async Python.
  - nurettin 6y ago
    I made a python clone of multitail in just under a day thanks to being able to read multiple files simultaneously with async. It really is overpowered.
- euiq 6y ago
  The current stream interface is still somewhat awkward. Apart from the question whether the reader and writer really need to separate objects, there's also the problem that the write and close methods are synchronous—in order to use them correctly, it's necessary to throw in asynchronous calls to drain and wait_closed. There was a plan to fix this in Python 3.8, but that never went anywhere.
joppy 6y ago
> it's the easiest and most sensible solution to writing concurrent code in a way that won't become incomprehensible I don't think that async/await is necessarily the most sensible solution, there is also the "implicit" concurrency model used in Go, Erlang, and even Python (using gevent/eventlet). A big benefit of the "implicit" model is that it doesn't split code into async vs sync, and so you don't have two versions of every library, one for sync and one for async. In a lot of cases in fact, you can run existing Python code on gevent and have concurrency "just work", without having to spring async/await everywhere. Python's implementation of async/await is also particularly bad for teaching: not only do you now need to teach people that there are multiple ways to call functions, but async functions cannot be called from the CPython interpreter directly. (You can from the IPython interpreter though). I love concurrent programming, but I don't love the effect that async/await has on code - it makes for less re-usability, and has a more difficult mental model to grasp than the implicit style. And when you can just import and monkey-patch Gevent to get all of the benefits of re-writing your entire codebase to be async/await, why would you?
- jordic 6y ago
  Mostly agree around reusing existing libs, and being and split point on the community, but I also can't understand why so many detractors. It's a tool and does it's job quit well. Anyway, in my test I prefer explicit and don't like monkey patching :)
  - joppy 6y ago
    I think the whole monkey patching thing is a bit of a red herring, gevent changes the python execution model enough that there may as well be a "gpython" command which runs Python - Python+gevent may as well be a different distribution of Python. But even so, is the cost of having to run a monkey patch (or some other startup script) greater than the cost of having to rewrite an entire ecosystem of libraries? I don't think so, not by a long shot. Just look at the whole "aiolibs" project to see how ridiculous this has become. Are some of those libraries better put-together than their originals? Sure. Is it worth splitting an ecosystem in half and having one half not even able to call into the other half? Absolutely not.
wdroz 6y ago
When the async keyword was released in Python, that was during the "callback hell" era of Javascript. The first codes using async in Python were mostly written by developers coming from the JS world. Reading code written that way may have turn off a lot of Python devs. IMO, 2020 async code is cleaner in both Javascript and Python, maybe some haters would change their mind if they give a second chance to "newer" async codes.

nurettin 6y ago

I had so much trouble getting the python tcp client to work like I wanted it to. Then I tried my hand on the async tcp client and was pleasantly surprised how simple it was. reader, writer = await asyncio.wait_for(asyncio.open_connection(), connect_timeout) line = "" while True: line = await asyncio.wait_for(reader.readline(), read_timeout) if line == b"": break yield line

andrewstuart 6y ago
I've written a bunch of things that were really well suited to async Python including an mpjeg server, a queueing server and a process management server that monitors the stdout and stderr of various processes and reads them in real time and acts upon the messages it reads. Each one of those applications was made possible comprehensible and even easy by async Python.
- nurettin 6y ago
  I made a python clone of multitail in just under a day thanks to being able to read multiple files simultaneously with async. It really is overpowered.
euiq 6y ago
The current stream interface is still somewhat awkward. Apart from the question whether the reader and writer really need to separate objects, there's also the problem that the write and close methods are synchronous—in order to use them correctly, it's necessary to throw in asynchronous calls to drain and wait_closed. There was a plan to fix this in Python 3.8, but that never went anywhere.

joppy 6y ago

> it's the easiest and most sensible solution to writing concurrent code in a way that won't become incomprehensible I don't think that async/await is necessarily the most sensible solution, there is also the "implicit" concurrency model used in Go, Erlang, and even Python (using gevent/eventlet). A big benefit of the "implicit" model is that it doesn't split code into async vs sync, and so you don't have two versions of every library, one for sync and one for async. In a lot of cases in fact, you can run existing Python code on gevent and have concurrency "just work", without having to spring async/await everywhere. Python's implementation of async/await is also particularly bad for teaching: not only do you now need to teach people that there are multiple ways to call functions, but async functions cannot be called from the CPython interpreter directly. (You can from the IPython interpreter though). I love concurrent programming, but I don't love the effect that async/await has on code - it makes for less re-usability, and has a more difficult mental model to grasp than the implicit style. And when you can just import and monkey-patch Gevent to get all of the benefits of re-writing your entire codebase to be async/await, why would you?

jordic 6y ago
Mostly agree around reusing existing libs, and being and split point on the community, but I also can't understand why so many detractors. It's a tool and does it's job quit well. Anyway, in my test I prefer explicit and don't like monkey patching :)
- joppy 6y ago
  I think the whole monkey patching thing is a bit of a red herring, gevent changes the python execution model enough that there may as well be a "gpython" command which runs Python - Python+gevent may as well be a different distribution of Python. But even so, is the cost of having to run a monkey patch (or some other startup script) greater than the cost of having to rewrite an entire ecosystem of libraries? I don't think so, not by a long shot. Just look at the whole "aiolibs" project to see how ridiculous this has become. Are some of those libraries better put-together than their originals? Sure. Is it worth splitting an ecosystem in half and having one half not even able to call into the other half? Absolutely not.

wdroz 6y ago

When the async keyword was released in Python, that was during the "callback hell" era of Javascript. The first codes using async in Python were mostly written by developers coming from the JS world. Reading code written that way may have turn off a lot of Python devs. IMO, 2020 async code is cleaner in both Javascript and Python, maybe some haters would change their mind if they give a second chance to "newer" async codes.