Python 3.15.0 was released on October 9, with default UTF-8 mode worth checking in everyday scripts. More consistent defaults do not automatically convert existing GB18030 files to UTF-8. After an upgrade, inspect actual file encoding and I/O contracts before suppressing decoding errors.

The default decoding choice changes

PEP 686 enables UTF-8 mode from 3.15. File bytes and strings remain distinct: decoding interprets bytes under an encoding contract, while encoding converts text to bytes. A new default does not alter bytes already stored on disk.

Inspect old files and new interfaces separately

Suppose a fictional import tool reads GB18030 reports produced by an older system. Omitting encoding and depending on environment defaults can break after the default changes. Verify the producer’s format and specify it explicitly rather than repeatedly guessing encodings when text looks wrong.

If a new service specifies UTF-8, put that contract in interface documentation and tests. Explicit formats are easier to reproduce than one developer machine’s defaults. Preserve historical files without metadata and validate any conversion through a reviewable process.

A runnable mismatch example

from pathlib import Path
from tempfile import TemporaryDirectory

with TemporaryDirectory() as folder:
    p = Path(folder) / "sample.txt"
    original = "中文 sample"
    p.write_text(original, encoding="utf-8")
    assert p.read_text(encoding="utf-8") == original
    p.write_bytes(original.encode("gb18030"))
    assert p.read_text(encoding="gb18030") == original
    try:
        p.read_text(encoding="utf-8")
    except UnicodeDecodeError:
        print("Encoding mismatch detected")
    else:
        raise AssertionError("Expected a decode failure")

This original example was executed in the existing Python environment, checking UTF-8 and GB18030 round trips and an incorrect-decoding failure. It does not test Python 3.15 default mode and is not a benchmark of that runtime. Explicit encodings illustrate the byte-format contract.

Why silently ignoring errors is risky

Ignoring decode errors can drop characters. Identifiers, amounts or configuration may remain parseable after data loss while no longer representing the original content. Tests should check actual values, not only the absence of exceptions.

Use representative normal text, empty files, line endings and known incorrect formats to test input, output and failure paths. Historical-format compatibility is a separate condition; a new release announcement does not establish compatibility for every application.

More than an upgrade command

Google News coverage discusses additional features; this article focuses on encoding migration using the official release page and PEP. It reproduces no official performance figures and promises no application speedup. Check dependencies and text interfaces independently before choosing deployment timing.

中文版

Sources

Official source 1 · Official source 2

Prepared on October 13, 2026. If published after the planned slot, its article date retains that planned time.