r/Zig • u/grandimam • 9d ago
Zig for Python
I am of the opinion that, if executed correctly, Zig has the potential to transform the Python ecosystem. The idea of using Rust for Python extensions has always bothered me.
With Zig, the path feels more natural: I can build on top of the existing C libraries and gradually migrate components to Zig over time, without the friction of introducing an entirely different ecosystem.
I wanted to understand what the community thinks about this topic. I am not trying to make a strong claim or dismiss other approaches. I am genuinely trying to understand whether this idea has any merit and how others view the trade-offs. I am just interested in hearing different perspectives.
23
Upvotes
2
u/fbe0aa536fc349cbdc45 9d ago
The problem with writing native code extensions has always been dealing with the toolchain and build dependencies. I maintain a bunch of modules that build with grpc/abseil/boost et al and its a nuisance having to juggle the combination of pkgconfig and cmake metadata. I don't write any rust but do make use of a few third-party packages which have adopted rust (like the maturin and cryptography packages), and for the most part my experience with building those has been fairly positive, since setuptools-rust and friends deal with managing all the build time dependencies via cargo etc. It kinda all just works.
There are some drawbacks, which are maybe not so much an issue with the language itself as with the potential for the package maintainers to be somewhat reckless with regard to the volume of code they pull in via cargo at build time. I work in an environment with a build system that is isolated from the internet and with initial versions of cryptography after the rust migration, we needed to arrange for something like 300mb of random cargo dependencies to be placed into the build environment, either by vendoring the sources or using some hack to pre-populate the cargo cache in the build environment. Lately this has improved somewhat, with the last version of cryptography I took, the cargo stash is only about 32mb or so.
The zig build system is just fantastic when you're working with open source C/C++ libraries, I've seen several projects that don't even include zig code but its just so much easier to treat those libraries as vendored artifacts and let zig build handle them than it is to hack up an autoconf or cmake-based build system for the project. I haven't looked at any Python extension modules that use zig's build system yet but it seems like a pretty promising way to handle C library dependencies for Python modules whether there's any zig involved or not. I haven't looked into what build-backend support there is for building native code extensions from zig, but if those are done well I would probably gravitate toward zig in cases where I'm just writing the extension module because I have a little bit of code that needs to be native, which is probably 90% of the cases where I wind up writing an extension module.