Python 3.15 is out: check file encoding before changing your runtime

The release is real; readiness is a separate question

The Python Software Foundation’s release page lists Python 3.15.0 with a 9 October 2026 release date. Among its documented changes are UTF-8 as the default encoding mode and explicit lazy imports. The documentation also includes porting and compatibility notes. A release date establishes availability; it does not establish that a particular application or dependency is ready.

For a maintainer, the useful response is a small migration inventory. Name the application, its current interpreter, its dependency lock file and the way it reads and writes data. Then decide which change could affect an observable result. This turns a broad “upgrade Python” task into a set of checks that someone can review.

Start with the files your program reads

PEP 686 changes the default UTF-8 mode behavior. That makes implicit encoding assumptions worth checking, especially when a program exchanges files with another application. A successful launch is a weak test if the program has not yet encountered a file outside its usual examples.

Build a small fixture set: plain English text, accented characters, non-Latin characters, an empty file and a file deliberately encoded differently from your intended format. Label each fixture’s actual encoding. Keep binary inputs separate from text inputs; changing a text default should not become an excuse to decode arbitrary bytes as if they were valid text.

from pathlib import Path

sample = Path("encoding-check.txt")
sample.write_text("café | example", encoding="utf-8")
assert sample.read_text(encoding="utf-8") == "café | example"
sample.unlink()

This small example specifies the intended format and verifies one round trip. It is not a migration test for every file in your application. Test the actual import and export boundaries, including the application that consumes your output, before changing the production runtime.

Make the upgrade decision reviewable

Do not replace the current working environment while building the comparison. Use a separate environment with the intended interpreter and the same dependency definitions. If a package fails, distinguish lack of support from a missing build tool or a changed installation command.

Treat lazy imports as a measured change

The 3.15 documentation explains that explicit lazy imports defer loading until the imported name is used; an import failure can therefore occur at that later point. That changes when an error is observed. It should be part of the test design, especially for commands that only exercise some optional features.

Our recommendation is to compare a cold start, the first use of the affected feature and a subsequent use. Keep the environment and input stable. A startup improvement can move work into the first user action, so measuring only process launch can miss an important delay.

Do not apply a global option across an application just because a release headline mentions faster startup. First identify the imports that dominate the behavior you care about, then test a bounded change and its failure path.

A reversible rollout is more informative than a rushed one

Keep the old environment available until the staged application has completed representative work. Save the configuration, lock file and command used for each environment, and make the runtime version visible in diagnostic output. A deployment should have an observable success condition and a specific way to restore the earlier runtime.

For an internal script, acceptance might mean that known files produce identical results. For a service, it may include startup, one request path, background work and the consumer of exported data. Choose the checks that reflect the actual workload instead of borrowing a generic checklist unchanged.

Our own contribution here is the fixture and decision framework. We have not benchmarked 3.15 or certified a reader’s package stack. Reopen the release and porting notes when an issue appears, because a named new version alone is not enough context to diagnose it.