What Python warnings policy do you set for a fraud-scoring service's CI and production runs?

### The question behind the question A warning policy is a decision about **who is expected to act, and when**. Two audiences, two answers. A developer running the 340-case regression pack can fix a deprecated call today, so the strongest possible signal - a failed build - is appropriate. An operator watching a fraud-scoring service at 3 a.m. cannot fix a deprecated call, and promoting warnings to exceptions there converts a paper cut into an outage. So the same process is configured differently in the two environments, and that asymmetry is the answer. ### CI: fatal, with a debt register Run the test job with `PYTHONWARNINGS=error`. Every warning becomes an exception at the point it is emitted, which means the failing test names the exact call site. The immediate objection is real: a large dependency tree emits warnings you did not cause and cannot fix this sprint. Handle it with **pinned** exemptions, not a blanket retreat: ``` PYTHONWARNINGS=error,ignore:legacy cursor API:DeprecationWarning:some_driver.pool,ignore::ResourceWarning:third_party.client ``` Each entry names a message pattern and a module, so a *different* deprecation from the same package still fails. Keep the list in one reviewed file with a comment per line: who owns it, which upstream issue tracks it, when it is reviewed again. The list is a debt register; if it only ever grows, the policy has quietly become `ignore`. The alternative many teams reach for - promoting only their own category - is weaker but defensible as a first step: make `error` apply to your own library's warning base class and `default` to everyone else's, then tighten. ### Production: observable, never fatal In the service, call `logging.captureWarnings(True)` once during startup. From that point the warnings machinery routes messages to the standard logging pipeline instead of writing to standard error, so they land in the same aggregation as every other event and can be counted, sampled and alerted on. That is the crucial win: a deprecation rate that appears on a dashboard is a signal you can act on before the removal release, whereas standard error on a container is a place messages go to die. Set the action to `default` rather than `always` in a high-traffic process. `always` re-emits per occurrence and a warning inside a per-request path will flood the pipeline; `default` shows each source location once, which is the information content you actually need - the same line warning ten million times teaches you nothing more than it warning once. If the volume still matters, an aggregation counter around a `once` action is the next step. ### Set it before your code runs A policy installed in `main()` is already too late for anything emitted during import - and a surprising amount is. This bites hardest during exactly the kind of change that reshuffles imports: a team untangling a circular import at startup moves module-level work around, and the deprecations firing during import are attributed and filtered before the entry point executes, so a filter installed there never sees them. Configure through `PYTHONWARNINGS` in the process environment, or `-W` on the command line, so the machinery is configured before the first import. Keep runtime `filterwarnings` calls for the narrow cases where the decision genuinely depends on runtime state. One related constraint: because the filter list is process-global with no locking, a service that mutates filters at runtime while serving concurrent work has a race on its own configuration. Another reason to set it once and leave it alone. ### Your own deprecations Policy is not only about consuming warnings. For code you own and other teams call: - Emit with `stacklevel=2` so the message names the caller's line, and so it is attributed to a module the caller's filters can select. - Define one warning base class per library so consumers can silence you without silencing everything - a blanket `ignore` is what you get otherwise, and it silences the next deprecation too. - Give a removal version in the message text, so the reader knows the deadline without opening a changelog. - Since Python 3.13, `warnings.deprecated` marks a function or class as deprecated for both the runtime and type checkers, so a static check can surface it before anything runs. ### What good looks like Deprecations fail the build; production counts them and alerts on a rising rate; the exemption list is short, pinned and dated; and a warning emitted by your own code names the caller's line and its removal release. The failure mode this prevents is the ordinary one: a dependency upgrade that removes a function which had been warning, unheard, for two minor versions.