One big difference is the c/c++ standards say that messing with a variable in multiple threads without locks is undefined behaviour, while Python claims there at least won't be an interpreter crash.

Right. The options in this area are:

- Don't check. Programs will crash if a thread-local variable is passed outside the thread (C, C++)

- Naive interpreter. Everything works, slowly, because the worst case code is used for everything. (CPython)

- Really clever just-in-time recompilation when what seemed to be thread-local suddenly gets accessed from another thread. (PyPy, Java?)

- Compile time checking to prevent this. (Rust)

- No threads (classic Javascript)

- Explicit shared areas into which only certain types can be placed (ECMAscript 2018)

I fail to see how what you said is relevant. All you've said is that Python & C/C++'s memory models are different from each other, which yes they are & no one has stated otherwise. My interpretation of the claims made were:

1. Python doesn't have thread-local variables 2. Python's memory model around threading is what prevents any optimization.

Both are clearly incorrect. For example, take Java. You have the same behaviour as Python: your VM won't crash & your code won't even generate a panic. Java clearly has thread-local variables & an optimizing compiler.

Python's inhibition around optimizing is partially around the guarantees they make around APIs that do self introspection but mainly around keeping the interpreter simple. For a counterpoint see PyPy, Cython, JPython, IronPython etc which optimize Python just fine. They mostly trip over module extensions being tied directly to the non-standardized CPython module API & that API is tied intimately to implementation decisions of CPython.