Put Python 3.15 Through Your Production Tests
Python 3.15.0 became stable on 9 October 2026. The migration decision now belongs with the application owner. A release announcement can identify changes; it cannot accept the consequences for a particular service.
Establish what changes in your service
UTF-8 becomes the default, changing locale-dependent file behaviour, particularly on Windows. Make required encodings explicit; test imports, exports, tools and logs.
Explicit lazy imports, or global lazy mode, defer loading, errors and side effects until use. Check registration, monkey-patching, commands, failures and eager initialisation; measure startup rather than assuming gains.
For a concrete acceptance exercise, ask a service owner to choose one real transaction and describe its expected result before the team runs it. Keep that expectation separate from the observed output. Otherwise, an engineer can unconsciously redefine success around whatever the new environment happens to produce.
Suppose a customer export is the chosen transaction. The reviewer should know which customer cohort, reporting period and approved destination the result represents. A comparison that loses one of those boundaries may be technically repeatable while answering the wrong business question. Record who is authorised to accept a difference, not just who ran the comparison.
Make the build decision reproducible
Free-threaded stable ABI support may require extension changes; otherwise separate abi3/cp315t builds remain relevant. Official Windows 64-bit binaries use tail-calling; macOS installers enable free-threading support. Benchmark the deployed build.
Verify wheels in clean OS/architecture environments, exercise source builds and extension imports, then test the service. Retain the interpreter, ABI, dependency lock and rollback point.
The handover should let another person reconstruct the approved result without relying on the original engineer’s memory. Give the evidence a stable reference and identify the environment it describes. An unlabelled screenshot in a chat is a poor acceptance record because its relationship to the proposed production change is easy to lose.
A useful review meeting ends with a decision about the service, not a vote on whether the installation looked healthy. If the evidence covers only part of the agreed transaction, accept that part explicitly and leave the remaining obligation open. That distinction also gives the next shift a clear starting point.
Keep the platform warning in scope
On macOS 27, IDLE/Tk menu dialogs can hang. This is not general interpreter failure. Test those workflows or defer the OS change.
Separate the decision to adopt an interpreter from the decision to change an operating system. Bundling two approvals into one ticket can make ownership ambiguous: one team may believe it accepted only the application result while another reads the same signature as clearance for the whole desktop environment.
Assign the next support decision now
PEP 790 plans roughly bimonthly bugfixes for two years, then source-only security releases until about October 2031.
Keep a named owner and review date beside the acceptance record. The next decision should not depend on someone remembering why a previous exception was granted. A deferred obligation needs a destination and a checkpoint, rather than a reassuring status colour.
The dated Python 3.15 Lifecycle record is a tracking aid, not a replacement for current release evidence. Keep older-branch decisions separate in our Python 3.10 support analysis. The practical outcome is an approval that another owner can understand, challenge and reproduce.
