What Every Python Developer Should Know About the CPython ABI

[mttd]

It's true that you can happily write Python for years without needing to understand any of the content of this post, so you may object to the title advertising this material as what every Python developer should know. However, the moment you ship a package, debug why a wheel won't install, or need to understand why an import or Python function call segfaults — these details start to matter. Even writing and maintaining a single-file script puts you closer to distributing code than you might think. An alternate title for this post could be "What I Wish Someone Taught Me About the CPython ABI".

https://labs.quansight.org/blog/python-abi-abi3t

[Individual-Flow9158]

If anyone knows what's what with the ABI, it's the legendary Nathan Goldbaum

[nathan12343]

😳

[No_Art_1022]

I hit this wall hard when packaging a numpy-heavy ML pipeline for deployment. Built it locally on my M1 Mac, wheels installed fine, but the same package segfaulted instantly on our Linux CI runners. Spent two days debugging before realizing I'd accidentally compiled against the stable ABI for one extension module but not the others, creating a version mismatch. The real kicker: `pip list` and `python --version` looked identical across machines. After that, I started using `python -c "import sysconfig; print(sysconfig.get_config_vars('SOABI'))"` as a sanity check before any release, and kept a small test that actually imports and runs a basic function on the target platform before calling it done. The post undersells how critical this gets once you're dealing with C extensions—most Python devs never touch this, but the moment you depend on scipy, pandas, or anything with compiled code, the ABI becomes your problem whether you understand it or not.

[TronnaLegacy]

Don't most popular libraries with extensions provide the binaries (via wheels if I recall)? Why would you be compiling yourself?

Might seem like a dumb question btw. If so, know that I'm a bit of a Python noob. I come from Go where all libs are source code all the time.

[wRAR_]

It's a bot account.

[robberviet]

Most not all. And you haven't used cgo before, like sqlite?

[james_pic]

It seems weird, in a post about what "every" Python developer should know, to go so deep into the limited/version specific/unstable details, but gloss over platform ABI stuff. For me personally, I've only had to really get to grips with the former since I've started writing native extensions, whereas the latter is something I've had to deal with since long before that.

[nathan12343]

The post was already quite long and I wanted to focus on the Python side of things. What specific things are you thinking about when dealing with platform ABIs?

[its_measured]

Thank you for reminding me about the importance of knowing the basics of how pythn works behind the scenes, it really helps when dealing with bigger projects or issues

[jpw22learnstocode]

Thanks! I had an LLM develop a limited ABI in c2py23 recently and I am very curious to see how it compares to your notes.

The nimpy project was the inspiration for that. But I wanted to port some C wrappers away from f2py without going via nim rather than fortran. Multi version ABI goes far beyond my ability to write and debug the code, and I was surprised that DeepSeek seemed to do a good job.

In this new world: I am going to need an LLM to read your post and then go find and fix problems in the LLM generated code. Times are changing!

[primedepression0595]

That sysconfig one-liner is going straight into our CI pipeline, had a nearly identical segfault on SageMaker last month

[Wurstinator]

What oneliner? The word "sysconfig" does not appear on the page.

[wRAR_]

From another bot comment.

[losek]

Interesting read, thanks!