You’re either mixing stuff up or need to be more precise in your communications.
A “data race” is simultaneous access of memory from multiple threads, where at least one access is a write. It’s undefined behaviour in modern compilers (including LLVM therefore Rust).
Rust prevents that (except unsafe), as does Python.
All “semantic” concurrency bugs that can be written in Python can also be written in Rust.
that's a correct definition of a data race at one level of abstraction, although the definition of 'simultaneous' required to make it a correct definition is broader than the one you're using; the relevant definition of 'simultaneous' is hairy, but in the case of two threads making a single access each, it is that either thread can be first. it doesn't require the accesses to literally happen in the same clock cycle
another definition of a data race condition is that it's a case where different interleavings of thread accesses to shared data produce different results. see https://en.m.wikipedia.org/wiki/Race_condition for more details and background on the concept
such bugs can be written in rust with unsafe, but not without it
hmm, thinking about it more, i wonder if what i'm saying makes sense
What you're saying makes sense, but I still don't think it's right. Imagine the classic broken bank-balance update algorithm from concurrency 101. It's safe Rust to individually wrap every operation with a lock instead of wrapping the entire transaction [0]. Both Rust and Python prevent data races as narrowly defined by the Rust docs [1], but semantic bugs like that can easily sneak into your code if you aren't careful.
Not to mention, Rust chose not to do anything about the memory fence problem. You're probably mostly fine on x86, but acquire/release semantics and all that nonsense still apply when writing concurrent algorithms in Rust (you'll often get lucky if you have something like a queue/channel and use message passing, since implementations of those often have a few fences internally, probably the fences you need for semantic correctness in your own algorithms). You're a lot more likely to see that sort of problem crop up in embedded work.
[0] That's obviously a bad idea, but more intricate concurrent algorithms are tricky to write in Rust for the same reason they're tricky to write in other languages. You get a bit of help from the compiler which you wouldn't really in Python if you design things to leverage the type system and prove the invariants you need to uphold, but the compiler doesn't know about any of those invariants aside from data races.
A “data race” is simultaneous access of memory from multiple threads, where at least one access is a write. It’s undefined behaviour in modern compilers (including LLVM therefore Rust).
Rust prevents that (except unsafe), as does Python.
All “semantic” concurrency bugs that can be written in Python can also be written in Rust.