There's a working POC out there for modifying tuple elements that relies on the fact that id() returns real memory addresses, so I don't see it as a harmless thing. Also, Rust is only worrying about code that's put into its compiler, whereas Python has to worry about any code that might be injected into a running process, which is vastly easier than in Rust. The situations don't really compare.

It's also part of defense-in-depth. If there's no good reason to make it trivial for people to locate TLS-specific data structures in memory, why make it trivial? It's probably still possible (turns out everything is...), but it's worth raising the complexity and lowering the reliability by making someone jump through crazy hoops to get it.

> The second issue seems like the big blocker. Your example does `ctypes.CDLL("libssl.so.1.1")`, but there's no guarantee that this will find the same libssl that the `ssl` module is linked against.

On Windows, it's spelled "libssl-1_1", but it *is* guaranteed to load the right one. However, I'd rather encode this information somewhere inside _ssl than making it a guarantee (as presumably OpenSSL 3.0 will change this name structure).

Also, this is not the same as ssl._ssl.__file__. So yeah, this aspect is not very portable, which is why I'd rather it just be exposed as a "call OpenSSL function on this context by name".

> I don't want to import ctypes from the ssl module code.

Import it in the function when it's called, then. Reimports are so close to free they're basically irrelevant, and if your tight inner loop includes TLS then it's not actually a tight inner loop, so looking in sys.modules isn't going to hurt anyone.

I would definitely push back on importing it eagerly in ssl.py :)