A fraud-scoring service reads a cached rules file with open() and no encoding=, and one host decodes it as mojibake. How would you find every such call site before the next release?

### Why the bug shows up only on one host A text-mode `open()` with no `encoding=` decodes with the locale encoding, which is a property of the machine. The fraud-scoring service writes a cached rules blob on a host whose locale is UTF-8 and reads it back on a replica whose locale is not — or reads a cache file that a *previous* release wrote under a different locale. Either way the bytes are fine and the decoding is wrong, so the failure is silent: the file loads, the strings are subtly corrupted, and the stale cached value keeps scoring traffic until someone notices the accented merchant names. A crash would have been kinder. With a three-week release train, the expensive move is to fix the one call site you found, ship, and discover the next one three weeks later. The goal is an inventory in a single cycle. ### The auditing switch PEP 597 (3.10) added `EncodingWarning` and the interpreter option that emits it. Start the process with `-X warn_default_encoding`, or set `PYTHONWARNDEFAULTENCODING=1`, and every construction of a text stream without an explicit encoding warns — `open()`, `io.TextIOWrapper`, and stdlib call paths that build one for you. Crucially the warning is reported at the *caller's* line, not inside the io module, so the output is a list of files and line numbers you can work through. `sys.flags.warn_default_encoding` exposes the switch to code that wants to behave differently under audit. The warning is inert by default: without the option, `EncodingWarning` is never emitted, so there is no cost to leaving it off in production. In CI, escalate it with `-W error::EncodingWarning`, which turns each hit into a test failure and prevents regressions once you have cleaned up. ### Working the list Each hit deserves a decision, not a blanket edit: * **Data the service owns** — its cache files, its config files, its fixtures, anything it wrote itself. Pass `encoding="utf-8"`. This is the majority. * **Text produced by the user's environment** — output captured from a console tool, a file the operator hand-edited on a Windows box. Pass `encoding="locale"`, which is the same runtime behaviour as before, states the intent, and suppresses the warning. * **Not text at all** — anything where the exact bytes matter. Open in binary and decode explicitly where the knowledge lives. A cached artefact deserves one more step: a file written under a mis-decode is already poisoned, so plan invalidation. Versioning the cache key, or writing a small header the reader validates, converts "a stale cached value silently scores wrong" into "the cache misses and rebuilds". ### The limits of the technique The warning is a *runtime* signal. It fires only for code that executes, so its coverage is your test suite's coverage; a rarely taken error path stays invisible. Two complements are worth the effort: 1. **A static sweep.** A grep or a lint rule for text-mode opens with no encoding argument catches unexecuted code. Several third-party linters ship such a rule; the point is that the two techniques have complementary blind spots. 2. **Process-wide UTF-8 mode.** `PYTHONUTF8=1` in the deployment makes every remaining implicit open — including inside dependencies you will not be editing — default to UTF-8. It does not fix explicit-but-wrong encodings, and it turns previously silent mis-decodes into `UnicodeDecodeError`, which is why you want the audit *first*: you want to know what will start failing before it starts failing in production. ### Confirming the diagnosis first Before any of it, prove the theory rather than assuming it. Read the artefact in binary and inspect the bytes: a UTF-8 encoded `é` is the two bytes `0xC3 0xA9`, and text that decodes to a two-character sequence beginning with `Ã` is the signature of UTF-8 bytes read through a single-byte codec. Compare `locale.getencoding()` and `sys.stdout.encoding` between a healthy host and the sick one; the difference is usually a missing `LANG` in a service unit or a slimmer base image. Fixing only the host's locale is tempting and wrong — it leaves the same landmine for the next environment. Make the code state its encoding, and use the environment change only as immediate mitigation. ### What good looks like afterwards One CI job runs the suite with the warning escalated to an error, the deployment sets UTF-8 mode, every remaining implicit open is a conscious `encoding="locale"`, and the cache carries a version so a bad generation cannot outlive the release that produced it.