Author: Emma Smith
Created at: 2025-11-18 01:47
Number: 54
Clean content: Donghee Na: What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? I think this section covers that: Emma Smith: Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. The current implementation is really a proof of concept, so there are a lot of places it could improve. It started with myself wishing to see how hard it would be to integrate Rust with cargo into our existing build system. A Rust _base64 module in CPython will look a bit different from the current proof of concept I hope. I expect extension modules will likely be able to be to be 80% safe hand-written code or more. That being said, building out the safe abstractions will take time and effort to do properly. So I think I would say, if you want to see something like where I hope to end up, look at PyO3, where the vast majority of hand written code is safe. Donghee Na: Another thing: could you compare build times and performance between the C version (with PGO + LTO) and the Rust build? I think that would make the PEP much more balanced and fair for reviewers. @Eclips4 found that his hand-rolled implementation that does not use any SIMD is about 1.6x faster than the _binascii implementation in use today. It’s hard to make a “fair” compilation speed benchmark because there are many variables that can come into play and knobs that can be tuned. The added Rust code will also necessarily add more compile time because we aren’t removing code by introducing _base64 .
