What is the difference between Thread.start() and Thread.run() on a threading.Thread?

## Two methods that are not alternatives `threading.Thread` is a small Python object that wraps an operating-system thread which **does not exist yet**. Two of its methods look interchangeable and are not: * `run()` is an ordinary method that *holds* the work. Its default implementation calls the `target` callable you passed to the constructor with the stored `args` tuple and `kwargs` dict. * `start()` is the only call that asks the platform for a real thread and arranges for `run()` to execute inside it. So `Thread(target=f, args=(1,))` and a subclass that overrides `run()` are two spellings of the same idea, and neither of them runs anywhere until `start()`. ## What start() actually does `start()` checks that the object was initialized and has not been started before — a second call raises `RuntimeError: threads can only be started once`. It registers the thread in the module's bookkeeping, asks the OS for a thread, and blocks on an internal event until the new thread has signalled that it is running, then returns. Inside the new thread a bootstrap function calls `run()`, catches anything that escapes and routes it to `threading.excepthook`, and finally unregisters the thread. Calling `run()` directly skips every part of that. You get a plain method call on the calling thread: fully synchronous, no parallelism, no `is_alive()` transition. The tell-tale symptom is code that "uses threads" and takes exactly as long as the sequential version, with `threading.current_thread().name` printing `MainThread` everywhere. On CPython 3.14 there is a second, sharper consequence: the default `run()` deletes its references to `_target`, `_args` and `_kwargs` when it finishes, so a `start()` on an object whose `run()` you already invoked by hand fails inside the new thread with an `AttributeError` rather than doing the work twice. ## Lifecycle and introspection * `is_alive()` is `False` before `start()`, `True` from `start()` until `run()` returns, and `False` afterwards. * `join(timeout=None)` blocks the caller until the thread finishes. It always returns `None` — a timed join tells you nothing by itself, so the idiom is `t.join(5.0)` followed by `if t.is_alive():` to detect a worker that overran. * `join()` before `start()` raises `RuntimeError: cannot join thread before it is started`, and joining `threading.current_thread()` raises `RuntimeError: cannot join current thread`. * `name` is a mutable label (the default looks like `Thread-1 (worker)`) and is what appears in tracebacks and log records; `ident` is the Python-level thread id, valid only while the thread is alive and reusable afterwards; `native_id` is the OS-level id, which is what process-inspection tools show, so it is the field to log when correlating with system-level output. * `threading.current_thread()` returns the running thread's object, `threading.enumerate()` returns a list of the currently alive `Thread` objects (including the main thread), `threading.active_count()` is that list's length, and `threading.main_thread()` returns the thread the interpreter started in. ## Passing work in and getting results out Arguments go in as `args` (a sequence) and `kwargs` (a mapping); the perennial mistake is writing `args=(x)` instead of `args=(x,)`, which passes the *contents* of `x` if it happens to be iterable, or raises immediately if it is not. Results come back through shared state — an instance attribute on a `Thread` subclass, an appended list, a thread-safe channel — because `join()` gives you nothing. If you want a value and a propagated exception, you want a pooled worker's future rather than a bare `Thread`. ## target= or a subclass? Prefer `target=` for a plain function; it keeps the callable independently testable. Subclass `Thread` when the worker owns state or needs several methods: override `run()`, call `super().__init__()` first (nothing else works if you do not), and keep the constructor cheap, since it executes on the *creating* thread. Do not override `start()`. ## The knob nobody looks at `threading.stack_size()` reads the stack size used for threads created afterwards in this process, and `threading.stack_size(n)` sets it. `0` means "platform default". It matters in two situations — a worker that recurses deeply and blows its stack, and a process creating very many threads where the reserved address space per thread adds up. It raises `ValueError` for a size that is too small or badly aligned and `RuntimeError` where the platform will not honour it, and it never affects already-running threads or the main thread.