Asyncio: A library with too many sharp corners

by chubot • 12 months ago

121 99 12 months ago

TZubiri• 12 months ago

Only experience with this thing was when working with a node dev that was trying out python. What a mess, he didnt quite get how processes or threads worked, just learned node's model event / promise models and brought them to python

zdragnar• 12 months ago

In all fairness, that's a pretty common experience with any transition between dislike platforms.

I'll never forget one Java developer who transitioned to JS frontend work (pre-typescript days). Try/catch everywhere.

There's a semi-accurate mindset that "good developers are good in any language" as if software engineers are fungible resources, but the transition time to a novel paradigm isn't really well appreciated.

mbb70• 12 months ago

I have seen "you can write Java in any language" proven true many times.

The culture and idioms of Java impose great constraints than syntax.

Not meant as a knock on Java or Java developers.

bsder• 12 months ago

In the traditional model of concurrent programming using threads, there is no clean way to do cancellation.

The only solution is the one being complained about--for a thread to voluntarily check if it needs to be cancelled.

Java deprecated stop() for good reasons.

"Those who cannot remember the past are condemned to repeat it."

krferriter• 12 months ago

You can't always control what the thread is doing, like what code is being executed. Even if you put flags and ensure your code is periodically checking them, your code is not necessarily the only thing being executed by the thread. It may be calling into external code. You need a way to interrupt it.

zahlman8• 12 months ago

No, that's exactly why you must not have "a way to interrupt it". Doing so could leave said external code in an invalid state and there would be no plausible way to do anything about it.

Spivak• 12 months ago

You can't always control what the thread is doing, like what code is being executed.

If this is the case then you can't use threads for this workload. If you're calling into some external code that could be doing whatever then one of the things it could be doing is holding locks. If you want a unit of execution you can murder with prejudice then you need the operating system's help which means a process.

On both Linux and Windows the situations where you can safely kill a thread is when you have complete control and knowledge of what's running in it, the very opposite of when people want to be able to kill threads.

zbentley• 12 months ago

Agree. If genuine pre-emptive cancellation from the outside is needed, all languages support the primitive which allows that: a process.

Many of the tradeoffs that come from using a process rather than a thread descend directly from that property of support for arbitrary-point cancellation.

mikert892• 12 months ago

the real problem is python, great at the start of a project, by the end i am dying to rewrite in java.

echelon5• 12 months ago

Python needs a version 4 to make a clean break:

- runtime optionally type checked interfaces

- make depending on system python an antipattern

- a reasonable package manager with lockfiles and transitive dependency versions

- package org namespaces

- steps towards hermetic builds with less linking against system libraries and dependencies

- cleanup and slimming down of the standard library. Removal of cruft. Less "batteries included" so people lean more on packages and enforcing good practices with packages.

Jabrov• 12 months ago

The latest versions of Python 3 already have or can do most of these things.

a_t483• 12 months ago

uv solves or improves 2,3,5. (It's scary how often lately I find myself saying or seeing someone say that)

---

For posterity -

    make depending on system python an antipattern

uv is virtual env, uv managed python executable first, opt in to system python packages only

    a reasonable package manager with lockfiles and transitive dependency versions

uv.lock, check. I think base pip also has transitive dependencies, though, and has since 2020?

    steps towards hermetic builds with less linking against system libraries and dependencies

I know there's build isolation for dependencies in uv, I'm not sure it solves the problem you have

What is it you mean by package org namespaces?

throw2022110401• 12 months ago

Python needs a version 4 to make a clean break

The tragedy of Python 3 is that they made the community go through a billion dollar migration but didn't tackle any of the hard stuff. And the reason they didn't was the Perl 6 debacle. So it's all Larry Wall's fault.

wiseowise• 12 months ago

Less "batteries included" so people lean more on packages and enforcing good practices with packages.

No, just no. If anything, Python needs more batteries built-in.

dimgl• 12 months ago

Sounds like trading one problem for another

mikert892• 12 months ago

idk maybe im old, but most of the high scale serious systems i have seen are in a language like java or c++. big important python systems are mostly from startups that succeeded and have trouble migrating off

spruce_tips• 12 months ago

checkout java 23. it has come a long way

9999000009994• 12 months ago

It's fine for very very small projects.

I have a couple of small tools which work well. One is basically a 200 loc script that coverts files.

The moment you need multiple files, the project is probably big enough where you really need a strong type system.

Java and C# fit extremely well for this. Both have caught up in terms of ease of use. The latest .net let's you run a C# file individually like a bash script.

The gift and curse of python is that it's really easy to do a lot. So you can be sloppy , just tossing stuff in, up until issues start to arise. Next thing you know you have a giant code base no one has any chance of understanding.

Still, it's a great first language. You can make small tools within a month. C isn't nearly as forgiving.

If you love the Python syntax, Nim is here.

FpUser4• 12 months ago

"Still, it's a great first language. You can make small tools within a month. C isn't nearly as forgiving."

If C and Python are the only options I would strongly vote for C being the first. It will weed out those who are unfit.

Myself I use many languages including Python but I started programming by entering machine codes in hex. Obviously I do not do it now but I think it did benefit me in general.

Philpax2• 12 months ago

This seems like a microcosm of the general design problems that pervade Python. It is a fundamentally quirky language.

alberth• 12 months ago

Any recommended alternative?

rangerelf2• 12 months ago

Nim?

pansa29• 12 months ago

Ruby is probably the most-similar popular language - a good choice for small projects/prototyping/exploratory programming. Personally I'm still using Python for this, but I'm basically still writing Python 2.7 (plus f-strings).

For larger projects, Go seems to follow the "Zen of Python" better than Python itself nowadays.

kstrauser2• 12 months ago

I’m bracing myself for the response, but.

Rust.

Yes, it clearly has a sharper learning curve than Python. But I think idiomatic Rust feels a lot like a good Python implementation of the same thing would, in ways I can’t quite explain. The borrow checker is certainly something to come to grips with, but it also nudges you to write code the way you should probably be writing it anyway. Don’t pass complex structures around and mutate them everywhere. Don’t return 5 kinds of object from the same function. Don’t go crazy with inheritance vs plain, understandable, testable functions.

Rust just feels right to my Pythonista brain.

remram• 12 months ago

At this point, there are good solutions to most of the problems. It is just hard and awkward to avoid the standard library bits and the common tools (e.g. use uv instead of pip, requests instead of urllib, pytest instead of unittest, marimo instead of jupyter, trio instead of asyncio...).

Of course having a "batteries included" language where the batteries hurt you is not great.

btown2• 12 months ago

I really wish the community had coalesced around gevent.

- no async/await, instead every possible thing that could block in the standard library is monkey-patched to yield to an event loop

- this means that you can write the same exact code for synchronous and concurrent workflows, and immediately get levels of concurrency only bounded by memory limits

- you'll never accidentally use a synchronous API in an async context and block your entire event loop (well, you can, if you spin on a tight CPU-bound loop, but that's a problem in asyncio too)

- the ecosystem doesn't need to implement libraries for asyncio and blocking code, everything just works

There's a universe where the gevent patches get accepted into Python as something like a Python 4, breaking some niche compatibility but creating the first ever first-class language with green-threading at its core.

But in this universe, we're left with silly things like "every part of the Django ecosystem dealing with models must be rewritten with 'a' prefixes or be abandoned" and it's a sad place indeed.

jeeyoungk• 12 months ago

I like `gevent` but I think it may have been too hacky of a solution to be incorporated to the main runtime.

"creating the first ever first-class language with green-threading at its core."

... isn't that what Go is? I think out of all languages I use extensively, Go is the only one that doesn't suffer from the sync/async function coloring nightmare.

pansa29• 12 months ago

I like `gevent` but I think it may have been too hacky of a solution to be incorporated to the main runtime

gevent's monkey-patching might be hacky, but an official implementation of stackful coroutines (similar to Lua's) need not have been.

Instead, stackless coroutines were chosen - maybe on merit, but also maybe because C#'s async/await keywords were in-vogue at the time and Python copied them.

igregoryca2• 12 months ago

the sync/async function coloring nightmare

I'm with you that function "coloring" (monads in the type system) can be unergonomic and painful.

... isn't that what Go is? I think out of all languages I use extensively, Go is the only one that doesn't suffer from the […] coloring nightmare.

Because it doesn't have Future/Promise/async as a built-in abstraction?

If my function returns data via a channel, that's still incompatible with an alternate version of the function that returns data normally. The channel version doesn't block the caller, but the caller has to wait for results explicitly; meanwhile, the regular version would block the caller, but once it's done, consuming the result is trivial.

Much of the simplicity of Go comes at the expense of doing everything (awaiting results, handling errors, …) manually, every damn time, because there's no language facility for it and the type system isn't powerful enough to make your own monadic abstractions. I know proponents of Go tend to argue this is a good thing, and it has merits. But making colorful functions wear a black-and-white trenchcoat in public doesn't solve the underlying problem.

(goroutines are nice, though.)

progval• 12 months ago

Erlang did it 20-30 years before Go

svieira• 12 months ago

Java 1.1 had green threads, so does Java 21+ (though Java 21's green threads are actually an M:N threading model not the M:1 threading model of Java 1.1).

nbsande• 12 months ago

While having the same code for sync and async sounds nice, monkey patching code at runtime seems hacky. Any library that wants to use a lower level implementation of network calls would need to handle the monkey patching themselves i assume.

jerf• 12 months ago

The idea would be that if this was accepted into the core as the way to go forward, it wouldn't be "monkeypatched" anymore, it would just be in core, officially supported.

happosai• 12 months ago

Green threads, now THAT's a buzzword I haven't heard for a long time...

icedchai• 12 months ago

I worked quite a bit with gevent'd code about 10+ years ago and also agree. Dealing with function coloring is incredibly non productive. This is one of the things "go" got right.

pas• 12 months ago

the sans-IO approach seems roughly correct

libraries provide pure processing machines that pull data in through well defined input functions (and output through return), and then it's up to the callsite (or host code or however we want to call our code) to decide what kind of color to paint the whole thing eventually.

this helps testability and composability too.

(of course this is not new, there was Scala's Iteratee and there's full program interpretation ... https://zio.dev/1.0.18/overview/overview_background/ )

jononor• 12 months ago

Agreed. I chose gevent over asyncio for a backend in 2019, and we still using it. Works pretty well. No plans to phase out gevent just yet.

Though the community has clearly centered on asyncio by now. So if I were to start a new backend today, it would reluctantly be asyncio. Unfortunately...

pansa29• 12 months ago

asyncio has so many sharp corners and design issues [...] bordering on being fundamentally broken
other languages and libraries did what asyncio does significantly better
it is baffling how the library made it out of provisional status with such glaring flaws

Unfortunately this seems common in Python 3.x. The hype-cycle focuses on a feature from another language(s), and Python rushes to add its own version without sufficient attention to its design, nor how the feature complements the rest of the language (if at all).

Async, type hints and pattern matching all fit this description. `match` is probably the worst offender - it seems to have been added mainly so that novices choosing a language will not veto Python because it's missing the current feature-du-jour. [0]

Type hints are at least having their flaws addressed - but the flaws can't be removed due to back-compat. This leads to a C++-like situation of "this is the modern way, these other approaches are deprecated". So much for "one way to do it".

[0] https://discuss.python.org/t/pep-8012-frequently-asked-quest...

privatelypublic• 12 months ago

I don't feel calling modern Match/Case syntax a "du-jour" feature is plausible. Are you referencing something else?

pansa29• 12 months ago

I don't feel calling modern Match/Case syntax a "du-jour" feature is plausible

I do. To be clear: I'm not saying that (well-designed versions of) pattern-matching will become less useful over time, but that they will become less fashionable.

Python will then, no doubt, add another language construct to appeal to those who choose languages solely based on a checklist of features.

gshulegaard• 12 months ago

I feel like this started/greatly accelerated when Guido stepped down as BDFL. Python at is on a path where the essence of what made it popular (readable, well designed, productive) is being crushed under the weight of it’s popularity. The language now feels bloated and needlessly complex in areas that were previously limited, but simple.

I recently chased down a bug where something was accidentally made a class variable because a type hint was left off it by accident and it clicked for me that Python is not the same language I loved at the start of my career.

pansa29• 12 months ago

I feel like this started/greatly accelerated when Guido stepped down as BDFL

Same, but I don't think that's the direct cause. Guido was actually in favor of all these features (as well as Walrus, of course) - so it's not like he would have vetoed them if he were still BDFL.

pansa29• 12 months ago

I recently chased down a bug where something was accidentally made a class variable because a type hint was left off it by accident

That's the reverse situation to one I've come across - a novice accidentally wrote `a : 4` instead of `a = 4` and was surprised that `a` was still undefined. There was no error because the `4` was interpreted as a type hint.

anal_reactor2• 12 months ago

The problem with any project is that at some point it's essentially complete, and all we need is small maintenance to keep it going. Google used to have an algorithm that pretty much solved web search. Tinder solved dating. Spotify solved music delivery. The problem is, you're sitting with a hundred managers and a thousand engineers and all these people expect growth. So you have to keep going, even if the only direction is down, because if you don't, you'll be forced out of organization and replaced by someone who does. So you do go down. And then everyone's surprised and playing the blame game.

ifwinterco• 12 months ago

It's funny because a lot of OSS suffers from neglect.

But Python and a few other popular OSS (TypeScript is another example) have the opposite problem: too much development time is spent on them, too many features are added, and the language bloats and becomes less nice to use

kstrauser2• 12 months ago

I liked Python’s pattern matching until I picked up Rust. Oh… that’s what we could have had? Sigh.

dagenix• 12 months ago

In my experience, the key to using asyncio is to use anyio. Anyio is an interface that you can use ontop of asyncio and fixes most of its shortcomings.

https://anyio.readthedocs.io

dcreater• 12 months ago

How does httpx compare?

zahlman8• 12 months ago

asyncio is for general concurrency; httpx is an http client. There is no comparison to make.

dade_• 12 months ago

Asyncio is too dull. Twisted for the win! My favourite insane package of wonders.

lormayna2• 12 months ago

And the best way to write unmaintainable and undebuggable spaghetti code.

o11c3• 12 months ago

For the (brief) C comparison, I'm really not sure why this talks about `pthread_kill` but not `pthread_cancel` ...

SkiFire134• 12 months ago

`pthread_cancel` still has most of the issues described.

o11c3• 12 months ago

It's standard, it's persistent, and it automatically handled by well-formed code. What's missing?

anal_reactor2• 12 months ago

Sir, this is Wendy's.

I have a feeling that the core issue is that author is trying to implement complex communication mechanisms with a tool that was designed for much more basic usage. I don't understand why half of the article is about cancellations while cancellations as a concept are wrong. Have you ever tried to cancel peeing mid-pee? It just doesn't work.

Not sure if the other half of the article is worth reading if first half has completely wrong premise. Or does this guy live in some utopian future where it's reasonable to assume that everything can be cancelled at any point.

drkrab• 12 months ago

“Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.” – Virding’s first rule of programming

Starlevel004• 12 months ago

Oh cool. I wrote this. 100% hit rate on random posts of mine ending up on HN.

lormayna2• 12 months ago

As somebody that has written couple of services with Twisted in the late '00s, I feel asyncio a breath of fresh air. This not means that it's perfect, but it's a lot more usable than Twisted. I know that it's not possible, but I would like to have in Python something similar to goroutines, waitgroups and channels that Go has.

rich_sasha• 12 months ago

A big issue with asyncio is IME the documentation. The main document is a tutorial-style tour of the features, scarcely mentioning the important details. These are often hidden in comments on seemingly unrelated features or, more likely, reddit and SE.

Some Python documentation indeed includes a tutorial, but also has a comprehensive documentation. This is not my experience with asyncio

snakepit• 12 months ago

I'm working on an ML platform in Elixir. Orchestrating CPU-intensive Python processes is central to the project, so I created a session based pooler called `snakepit` [1].

The latest revision is building a batteries-included gRPC Python bridge that enables streaming, bi-directional tool use, as well as an innovative variables feature for experimental ML inspired by ideas from DSPy's team.

One of the later project goals: A Python client that can manage the Elixir orchestrator that manages pools of Python, in a distributed environment. Maybe I'll call that submodule `snakepits`. In this embodiment, it will be an effective albeit much more sophisticated replacement for `asyncio` for some use cases.

[1] https://github.com/nshkrdotcom/snakepit

Asyncio: A library with too many sharp corners

Related Stories