Author: Dima Tisnek
Created at: 2025-11-19 07:09
Number: 131
Clean content: alex_Gaynor: dimaqq: A safe C equivalent would be two lines long. FWIW, I’ve tried pretty hard, but I can’t find a way to write a (readable) 2-line version of this function in C that retains the overflow checking. My take: if (len > PRECOMPUTED_CONST) return -1;
return (len + 2) / 3 * 4; My point was exactly about the fact that crustaceans worry about overflow checking, borrow safety, traits, etc., and write verbose code that is beautiful, while pragmatic folk reduce the problem, put safety limits leaving the implementation very short. After all, what’s the point of encoding a string that’s larger than a fraction of the total address space? The Rust overflow checker is only effective at ~3/4 RAM, at which point the argument and result cannot fit into RAM at the same time. Fancy Rust safety is totally appropriate for user-defined or external input (e.g. networking code, cryptography or json.dumps argument where some inner dict-like object may have a custom dunder method that does some “caching” but ends up modifying sibling elements in flight or creates cycles), while simple concepts should in my opinion remain simple, so that the code remains maintainable, ideally also by contributors who are not Rust experts. Which is why I’m calling for the equivalent of PEP-7 for Rust use in CPython. ShalokShalom: Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . There are CVE’s in safe Rust I’d go even further and decry “proven safe” as smoke and mirrors. Remember the BAN logic proof for the Needham–Schroeder protocol? To recap, every proof is against a certain fixed set of assumptions. Meanwhile what happens in practice is that software is reused in ways unpredictable a priori. RustBelt has proven something about Rust, but not about Rust use in CPython, or Rust use in 3rd party Python extensions and certainly not about Rust used within CPython when an arbitrary user program is run by the interpreter, with arbitrary additional extension, for arbitrary goals and with arbitrary thread model. Here my call is to move most of Rust exultations into the footnotes, and focus on tangible direct benefits instead: safer refactoring / faster reviews, broader contributor pool / potentially more approachable to new contributors who grew up with safe/typed languages, specific CPython core bug classes (not generic C bugs), cleaner (more self-documented) internal APIs, safer norms for 3rd party extensions, possibly safer/faster backport story, potentially better tooling, possibly CPython guts (e.g. regexp) shared as crates for other uses…
