Python 3.15’s Feature Freeze Is the Signal to Start Testing

Python 3.15’s first beta is more than a milestone for release managers. For teams that maintain services, libraries, C extensions, packaging hooks, or developer tooling, feature freeze is the point where migration work becomes realistic.

Real Python’s June roundup highlights the practical meaning of the beta: Python 3.15’s feature set is now locked, so the remaining cycle is about bug fixes, polish, and compatibility feedback. The official Python 3.15.0b1 release marks that transition, and 3.15.0b2 has already started the stabilization run.

Feature freeze changes the migration conversation

Before beta, testing can feel speculative because APIs and behavior may still move. After beta, the surface is stable enough for serious compatibility work. That does not mean beta builds belong in production. It means CI, package maintainers, and platform teams should start discovering breakage while core developers still have time to fix regressions.

What is now worth testing

Run application test suites, dependency test suites, type-checking workflows, wheels, build backends, packaging startup hooks, and observability tooling against the 3.15 beta. Pay special attention to projects that touch CPython internals, use C extensions, or rely on import-time customization.

The headline features are operational, not flashy

Python 3.15 is not just a syntax-news release. Several accepted changes are aimed at runtime behavior, extension maintainability, and production debugging. PEP 803 moves the free-threaded stable ABI forward, which matters for extension authors tracking the no-GIL path. PEP 799 adds a sampling profiler to the standard library for lower-overhead performance insight.

The sentinel built-in closes an old pattern gap

PEP 661 standardizes sentinel values, and the 3.15 docs now list a built-in sentinel. That sounds small, but it addresses a pattern Python developers have reinvented for years when they need to distinguish “argument omitted” from “argument explicitly set to None.”

Why library authors should care

Sentinels show up in public APIs, configuration systems, dataclass-like helpers, and serialization boundaries. A standard mechanism can reduce inconsistent private objects, awkward repr output, and subtle pickling or typing friction across libraries.

The beta window belongs in CI

The right move is not to wait for the final release and then discover failures under deadline pressure. Add an allowed-failure 3.15 beta job, run dependency upgrade checks, and file upstream issues with minimal reproductions. Projects with C extensions should also verify wheel builds and audit any unsupported CPython internal assumptions.

Free-threaded compatibility needs early eyes

Free-threaded Python remains a staged ecosystem transition. Even if your application does not plan to run without the GIL immediately, extension compatibility work is cumulative. Testing against the beta helps identify what is blocked by your code, what is blocked by dependencies, and what is blocked by packaging.

What to watch next

The next useful checkpoint is the release-candidate phase, when last-minute behavior changes become much less likely. Teams that begin now can enter that phase with a known compatibility list instead of an unexplored backlog.

A practical team checklist

• Add Python 3.15 beta to CI as non-blocking.
• Run the full test suite and capture import-time warnings.
• Build wheels for any native extensions.
• Try the sampling profiler on representative workloads.
• Review APIs that use private sentinel objects.
• Open upstream issues early, with small reproducible failures.

Python’s beta is a request for feedback. The teams that answer it early usually have the calmest final-release upgrades.

Featured image: “Learning to Code” by gdsteam, licensed under CC BY 2.0.