Hacker News Reader

> 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?

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 :)

It does something we were already doing worse than we were already doing it. In Python's case, it does it worse than we were already doing it in the same language. At least for me, this is why I don't have many nice things to say about it.

It's also fine to "prefer to be explicit", but it is weird to prefer to be explicit ONLY about whether a function can do the "switch stacks" operation on your behalf (not whether it can consume random numbers from the global RNG, not whether it can create files, not whether it can do blocking I/O, not whether it can open a server socket, not whether it can send HTTP requests, not whether it can write log lines, not whether it mutates its parameters, etc.), and to be explicit about it in a way that invites bugs that don't need to be possible to write (async functions produce a value that can then be awaited, so it's a bug to not await them when you meant to, or to await them when you didn't mean to, and it's common to write such bugs when adding an await operation to a formerly non-async function that is called by other formerly non-async functions).

I must say that python3.8 does a better job detecting not awaited awaitables.

Anyway,asyncio it's not new to python, the stdlib still has asyncore in it. There are still awesome web servers around (threaded) but using "asyncio" on the main thread. ZServer, medusa (look at what powers supervisor for example).

The file io thing it's still a pain, but same happens on node side.. but seems there is in the way something that will fix it.

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.

Someone should take care of it, but doesn't seem like a trivial problem.. btw, I also will be so happy to be able to reuse part of twisted core on asyncio services :)

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

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.

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.

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.

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.