Python 3.15 RC3: What to Test Before the Final Release

Python 3.15 is close to release, but it is not final yet. Python 3.15.0rc3 arrived on October 2 after last-minute lazy-import release blockers delayed the final release, now scheduled for October 9. For developers, the useful question is not whether to replace a working runtime today. It is which compatibility checks to finish while there is still time to report a problem.

Sources checked October 3, 2026. This is documentation-based analysis, prepared with AI assistance and editorial review, not a hands-on test of Python 3.15 or a benchmark. Commands are suggested checks for your own isolated development environment.

What RC3 means for your project

The official RC3 announcement describes a preview release and explicitly advises against production use. The updated release schedule lists October 9 as an expected date, not a guarantee. The announcement also says the 3.15 ABI is frozen for this release-candidate phase and encourages maintainers to prepare compatible wheels.

Those facts support a rehearsal, not an automatic deployment. A package installing successfully does not show that your scheduled tasks, data imports or production startup path still behave correctly. Keep the existing production interpreter and deployment image unchanged while you collect that evidence.

• Application developer: try RC3 on a disposable branch and compare the same workload with your currently supported runtime.
• Library maintainer: add a compatibility job, check supported platforms and investigate failures before changing your advertised support.
• Beginner: keep a stable interpreter for ordinary work; treat RC3 as an optional learning environment.

Create a separate environment, not an in-place upgrade

Install the preview from an appropriate official distribution alongside your existing interpreter. Confirm the executable before creating an environment. The example below assumes a POSIX shell and an installed executable named python3.15; Windows users must substitute the actual interpreter path and the environment’s Scripts\python.exe.

Before running this block: confirm .venv-py315-rc3 does not already exist; choose another new directory if it does. venv can reuse an existing directory. Never target your production environment.

python3.15 --version
python3.15 -m venv .venv-py315-rc3
.venv-py315-rc3/bin/python -c "import sys; print(sys.version); print(sys.executable)"
.venv-py315-rc3/bin/python -m pip --version

These commands create a local environment and report its interpreter; they do not prove application compatibility. A virtual environment separates Python packages, but it is not a security sandbox: it does not remove inherited credentials or restrict access to files and the network.

The venv documentation explains that environments belong to the interpreter used to create them and can be used without activation. Calling the environment’s Python directly also avoids ambiguity about which pip or test runner is on your shell’s path. If activation is confusing, our virtual-environment troubleshooting guide provides related background.

Check dependency installation separately from application behavior

Use your project’s existing dependency and lock workflow. Do not remove version pins or enable prerelease packages across the whole project merely to obtain a green installation. If you use a requirements file, run the following only after reviewing its package sources and build configuration. Package installation can execute code; use trusted dependencies in a disposable environment without production credentials.

.venv-py315-rc3/bin/python -m pip install -r requirements.txt
.venv-py315-rc3/bin/python -m pip check

pip check checks installed dependency relationships. It does not run your app. For a separate wheel-availability check, pip’s install reference documents --only-binary=:all:. That option rejects source distributions: a failure may reveal a missing compatible wheel or a package that normally ships only as source, rather than a Python defect. Test this in another fresh environment so installed packages do not obscure the result.

Record the exact interpreter build, operating system, architecture, dependency versions and installation failure. A report that says only “Python 3.15 does not work” gives maintainers little to act on.

Exercise real text files under the new UTF-8 default

Python 3.15 enables UTF-8 mode by default. PEP 686 explains the compatibility risk for code that previously relied on locale-based text encoding. An ASCII-only fixture can miss a problem in a real CSV export, configuration file or subprocess response.

Compare the same test suite with UTF-8 mode explicitly disabled and enabled. The command-line reference documents these switches and the default-encoding warning option.

.venv-py315-rc3/bin/python -X utf8=0 -X warn_default_encoding -m pytest
.venv-py315-rc3/bin/python -X utf8=1 -X warn_default_encoding -m pytest

This example requires pytest in your project’s test environment; substitute your own runner if needed. Include actual non-ASCII inputs, then assert their decoded content—not only that opening the file succeeds. When a file has a defined encoding, declare that encoding explicitly. Do not label a legacy file UTF-8 merely to silence a warning.

For an intentional locale-dependent contract, encoding="locale" expresses that choice, but it is not a universal portability fix. Identify the producer and consumer of each file before changing its contract. Treat differing results between the two runs as an investigation queue, not a reason to suppress every warning.

Keep lazy-import testing separate from the runtime upgrade

Python 3.15’s explicit lazy imports defer module loading until the imported name is used. PEP 810 explains that errors and import-time side effects can move to that first-use point. Ordinary imports are not automatically made lazy just because you install 3.15; the normal mode respects explicit lazy-import choices. The -X lazy_imports=all option is a broader, separate change.

First establish a baseline with your application’s existing import behavior. If you then experiment with laziness, check the paths that initialize plugin registries, install logging handlers or register commands. Launch a fresh process for each scenario: a module loaded by an earlier test can hide a first-use problem.

Useful scenarios include a help command, a rarely used subcommand, a plugin discovered by registration and an optional dependency that is missing. Check both successful execution and where failure appears. Do not infer that faster startup improves your full workload, and do not ship a global lazy-import flag solely because one command looks quicker.

Turn failures into a small migration record

Read the Python 3.15 porting notes for changes relevant to your code, including cleaned-up sqlite3 call signatures and removed deprecated APIs. The document is still labelled as draft during prerelease development. Check your project’s own warning filters too: pytest’s warning documentation explains how filters affect what you see.

Keep one short record per blocking issue:

• Reproduction: the smallest input and command that fails, with sensitive data removed.
• Comparison: the result on your current supported interpreter and on the exact RC3 build.
• Owner: your code, a dependency or an upstream interpreter report, supported by evidence rather than a guess.
• Exit condition: the version, patch or test result required before reconsidering the upgrade.

Maintain your current stable-version CI job while adding the preview job. A visible experimental failure is useful; an ignored job that nobody reviews is not readiness evidence. Recheck failures against the final release when it arrives instead of assuming an RC result will remain unchanged.

What should be true before you deploy?

Our suggested deployment gate is simple: the final interpreter is available, your dependency installation is reproducible on the target platform, representative workflows pass, and you can return to a known-good deployment. These are project decisions, not guarantees from the release calendar.

For a small application, the highest-value rehearsal may be one real data import, one scheduled task and one clean startup using the intended production configuration without live credentials. For a library, platform coverage and wheel distribution may matter more. Choose checks from your actual failure modes rather than copy a long checklist that nobody maintains.

Keep runtime migration separate from irreversible database or data-format changes. Record the existing deployment artifact and configuration needed for rollback; do not rely on being able to recreate them later. RC3 is an opportunity to find compatibility problems early. It is not a reason to rush a working production service onto a preview release.