What does CPython's `-X dev` development mode switch on at runtime?

**What development mode is.** Python's development mode is a *runtime* mode, not a build. You get it with `python -X dev script.py`, or by exporting `PYTHONDEVMODE=1`. Any ordinary release interpreter supports it: you do not need a `--with-pydebug` build of CPython, the ABI is unchanged, and every C extension you already have keeps working. What you pay is performance, which is why it belongs in local development, CI and diagnosis rather than in a production process. **What it turns on.** Six effects, every one of which also exists as its own switch: 1. **The default warning filter**, exactly as if you had passed `-W default`. This is the effect people notice first. CPython's normal filters ignore `DeprecationWarning` (except when it is triggered in `__main__`), `PendingDeprecationWarning`, `ImportWarning` and `ResourceWarning`; development mode displays all of them, including the ones raised from inside libraries you imported. 2. **Debug hooks on the memory allocators**, the same thing as `PYTHONMALLOC=debug`. Each block gets padding bytes on both sides and a fill pattern, and freed memory is overwritten. CPython then detects buffer overflows and underflows, use-after-free, freeing a block with a different allocator than the one that allocated it, and calls made without holding the GIL. A C extension bug that used to be a random crash three functions later becomes an immediate, located abort. 3. **`faulthandler`**, as if you had passed `-X faulthandler`, so a hard crash prints a Python traceback rather than only a signal. 4. **asyncio debug mode**, the same as `PYTHONASYNCIODEBUG=1`. asyncio then reports coroutine objects that were created and never awaited, logs callbacks and I/O handlers that hold the event loop past its slow-callback threshold (100 ms by default), records where each coroutine was created so a "Task was destroyed but it is pending" message can point at real source, and checks that calls come from the thread that owns the loop. 5. **`sys.flags.dev_mode` set to `True`**, so your own code — or a library — can branch on it and add extra checking of its own. 6. **Stricter argument checking on text encoding and decoding.** For speed, CPython normally validates the `errors` argument only at the first encoding error, and can skip the `encoding` argument entirely for an empty string; development mode checks both eagerly, so a typo like `errors="strick"` fails on the first call instead of on the one input that happens to contain a non-ASCII byte. Development mode also makes `io.IOBase` destructors log exceptions raised by `close()` instead of discarding them. **What it does not do.** It does not enable `tracemalloc` — that is the separate `-X tracemalloc=N` / `PYTHONTRACEMALLOC=N`, and combining the two is what gives a `ResourceWarning` the traceback of where the leaked object was allocated. It does not enable `EncodingWarning`, which needs `-X warn_default_encoding`. It does not turn warnings into errors: it *displays* them, and `-W error::DeprecationWarning` is what makes them fail. It does not add the C-level assertions of a debug build, and it is nowhere near as slow as one. **Scope and inheritance.** A `-X` option applies to the process you launch and is not passed on to children. The environment is inherited, though, so when you want a whole process tree in development mode — a runner spawning workers, or a `multiprocessing` pool using the `spawn` or `forkserver` start method — export `PYTHONDEVMODE=1` instead of passing the flag on one command line. At runtime, `sys.flags.dev_mode` tells you which mode you are in, and it is the honest way for a health endpoint or a start-up check to report it. **Why the mode exists as a bundle.** Each of its parts predates it, and before development mode existed you had to remember five separate incantations to get a strict run. Bundling them made "run it strictly" a single, memorable flag that a CI job or a new contributor can adopt without a checklist. The corollary matters just as much in production work: because they are still independent switches, you can take one without the others — `-X faulthandler` alone is cheap enough to run permanently, while the allocator hooks are not. **Why interviewers ask.** The answer separates people who have only written Python from people who have operated it. The follow-through is knowing where the mode belongs: on in development and CI, where the slowdown is irrelevant and the signal is valuable; off in production, where the allocator hooks and asyncio bookkeeping cost measurable latency and a surfaced third-party deprecation is noise rather than action.