Which encoding does open() use in text mode when encoding= is omitted?

A text-mode `open()` does not hand you the file's bytes. It stacks a decoder on top of a buffered binary stream, so you read `str` and write `str` and a codec converts in both directions. That codec has to come from somewhere, and when you do not name it, it comes from the *environment of the process*, not from the file. ## What the default actually is On CPython 3.14, omitting `encoding=` means the locale's preferred encoding, which `locale.getencoding()` reports. On most current Linux and macOS installations that is UTF-8, because the locales themselves are UTF-8. On Windows it is traditionally the system's ANSI code page — `cp1252` in much of the West, `cp932` in Japan, and so on. It also depends on how the process was started: a service under a minimal environment, a container with no locale configured, a cron job, and your interactive shell can all disagree on the same machine. That is the whole trap. The bytes in the file are fixed. The decoder is not. So the code path that works on a developer laptop fails on a build agent, and the failure is not a Python bug — it is an unstated assumption that finally got contradicted. ## The two shapes of the failure The loud shape is `UnicodeDecodeError`: the byte sequence is not valid in the assumed codec, and reading blows up partway through the file, often on the one row that has a non-ASCII character. Because most of the data is ASCII, this typically shows up late and looks data-dependent. The quiet shape is worse. Single-byte legacy codecs decode *any* byte, so nothing raises: a two-byte UTF-8 sequence turns into two nonsense characters. The text flows through your program, into a database, into a report, and the corruption is discovered by a human weeks later. By then the original bytes may be gone. The write side mirrors this. Writing text with the default encoding produces a file whose meaning depends on the machine that produced it, which is exactly what you do not want for anything another program will read. ## Saying what you mean There are three honest positions and Python lets you write all of them: * `encoding="utf-8"` — "this file is UTF-8." Correct for data your own systems produce and consume, for anything crossing a network or a container boundary, and as the default choice when you have no reason to think otherwise. * `encoding="locale"` — added in 3.10, this explicitly requests the machine's locale encoding. It is the right answer when you really are reading something produced by the local system in its own encoding, and it documents that intent rather than leaving a reader guessing. * `encoding="cp1252"` or another named codec — "this file came from a system that used that code page." Legacy imports live here. The point is not that UTF-8 is always correct; it is that *an unstated default is never a decision*. Someone reading the call cannot tell whether the omission was a choice or an oversight. ## Finding the call sites you already have Python 3.10 added `EncodingWarning` for exactly this. Run the program with `-X warn_default_encoding` or set `PYTHONWARNDEFAULTENCODING=1`, and every text-mode open that fell back to the locale encoding reports itself with a file and line number. Turning that warning into an error in a test run gives you a mechanical way to sweep a codebase: fix or annotate every hit, and new ones cannot creep back in. Calls that legitimately want the locale encoding are silenced by writing `encoding="locale"`, so the sweep converges instead of leaving permanent noise. The other lever is UTF-8 mode: `-X utf8` on the command line or `PYTHONUTF8=1` in the environment makes the interpreter behave as though the locale were UTF-8, which pins the default for a whole process. It is a good deployment-level belt-and-braces setting, but it does not remove the need to be explicit in code, because your library may be imported into someone else's process where that flag was never set. ## The neighbouring decision Once you have named the encoding you can also decide what happens when a byte still does not fit, which is what the `errors=` argument governs — strict failure, replacement characters, or dropping the offending bytes. Note only that this is a separate decision from the codec, and that reaching for a lenient handler to make a `UnicodeDecodeError` go away usually means silently damaging data rather than fixing the mismatch. Determine the file's real encoding first; choose a failure policy second. The interview-ready summary: text mode always decodes, the default codec comes from the environment rather than the file, on 3.14 that default is still the locale encoding, and the professional habit is to pass `encoding=` on every text-mode open.