Python does have real threading. The `threading` module provides os-level threads and synchronization primitives. The only difference between this and multithreading in C or Java is that CPython's GIL prevents more than one thread executing bytecode at a time. This prevents parallelism, but not concurrency.
Note this does not mean that python code is thread-safe by default. At most, you can theoretically rely on bytecode operations to be atomic, which means you'll need to synchronize multi-threaded code with mutexes, semaphores and higher-level synchronization constructs.
Python has cooperative threading. It's the same threading model used in the Erlang VM, Julia and many other dynamically typed languages. But preemptive threading vs. cooperative threading is orthogonal to whether data races can happen. Java threads are preemptive but data races can still happen.
While this is technically true it's quite misleading. The VM itself uses cooperative scheduling, but the Erlang compiler emits something akin to yields appropriately, such the net effect is preemptive scheduling. You can break it by calling a NIF that doesn't do the yields appropriately, but that's not the norm.
Preemptive threading means that the running thread can be paused by the system without ANY cooperation from the thread itself. Emphasis on "any". Python works roughly the same as Erlang. Every N bytecodes it checks if a thread is waiting to run and switches to that. Both are variants of cooperative threading.
Note this does not mean that python code is thread-safe by default. At most, you can theoretically rely on bytecode operations to be atomic, which means you'll need to synchronize multi-threaded code with mutexes, semaphores and higher-level synchronization constructs.