Why does a DeprecationWarning from an imported library not print by default?

### The default filter list A CPython 3.14 process starts with five entries in `warnings.filters`, in this order: ``` ('default', None, DeprecationWarning, '__main__', 0) ('ignore', None, DeprecationWarning, None, 0) ('ignore', None, PendingDeprecationWarning, None, 0) ('ignore', None, ImportWarning, None, 0) ('ignore', None, ResourceWarning, None, 0) ``` Each tuple is `(action, message-regex, category, module-regex, lineno)`. The list is scanned top to bottom and **the first match wins**; a warning that matches nothing gets the fallback action, which prints once per location. So `UserWarning` and `RuntimeWarning` are visible out of the box, while the four categories above are not - except for that first entry, which resurrects `DeprecationWarning` when the module it is attributed to is `__main__`. ### Why the split exists Before Python 3.7, `DeprecationWarning` was silenced unconditionally, and the result was that nobody saw deprecations until the removal release broke them. PEP 565 (Python 3.7) restored the middle ground now in place: a person *running* a program should not be shown that some dependency three layers down uses an old call - they cannot fix it and the noise is meaningless. A person *writing* the top-level script should be shown their own deprecated usage, because they can fix it right now. The module-name filter `__main__` is the mechanism that separates the two audiences. ### Why attribution is where the subtlety lives The module compared against `__main__` is not "the module that owns the deprecated function" - it is the module of the stack frame the warning was **attributed** to, which the emitter chooses through the `stacklevel` argument. A library that calls `warnings.warn(msg, DeprecationWarning)` with the default `stacklevel=1` attributes the warning to its own module, so the `ignore` entry matches and the user of that library never sees it, even from a script. The same library calling with `stacklevel=2` attributes it to the caller's frame; if the caller is the top-level script, the module is `__main__`, the first filter matches, and it prints. This is why a well-behaved library passes `stacklevel=2` on deprecations, and why two libraries can behave completely differently for the same category. ### Turning them on There are three lever positions, and which one you pick matters more than it looks. **At interpreter start, per run.** `-W default::DeprecationWarning` on the command line, or `PYTHONWARNINGS=default::DeprecationWarning` in the environment. The spec is `action:message:category:module:lineno`, each field optional, colons kept: `-W ignore:::third_party.legacy` silences one module, `-W error::DeprecationWarning` makes them fatal. Multiple `-W` options are allowed and later ones take precedence, and the raw strings stay visible in `sys.warnoptions`. This position is the only one that catches warnings emitted **during import**, before any of your code runs. **In code, coarse.** `warnings.simplefilter("default", DeprecationWarning)` throws away everything already configured for that category and inserts one entry. Convenient in a script; rude in a library, because it stomps on the application's policy. **In code, precise.** `warnings.filterwarnings(action, message=..., category=..., module=..., lineno=...)` inserts a fully specified entry at the **front** of the list, so the newest filter wins. The `message` and `module` values are regular expressions matched against the message text and the attributed module name - note that `module` is matched with `re.compile(module).match`, so anchor your patterns rather than assuming a substring test. `warnings.resetwarnings()` clears the list entirely, including the defaults, which is almost never what you want in application code. ### The practical failure mode A team upgrades a dependency, all tests pass, and a release later a function is gone. The deprecation had been firing for two minor versions into a filter that ignored it. The fix is policy, not cleverness: run the test suite with deprecations visible or fatal, so the signal arrives while there is still time to act, and keep the production process quieter. ### Related categories worth knowing `PendingDeprecationWarning` is the softer, earlier signal, still ignored by default and now rarely used - most projects go straight to `DeprecationWarning`. `FutureWarning` is *not* in the ignore list, and that is deliberate: it is the category for changes aimed at end users rather than at developers, so it is visible by default. `ResourceWarning` (unclosed files and sockets) is ignored by default because its attribution is unpredictable during garbage collection.