Beta releases exist to give library maintainers, framework authors, and application developers a chance to exercise the new interpreter under real workloads. The core team has made the stakes explicit: after beta 4 the goal is no further ABI changes, and the number of code changes after the first release candidate should be kept as low as possible. Consequently, the call to action is clear—test now, file issues promptly on the CPython tracker, and publish pre-release wheels so the wider ecosystem can validate compatibility.
Python 3.15 entered feature freeze with beta 1 on May 7. From that point forward the focus has been refinement rather than the addition of new language constructs. The feature set that will ship in the final release is therefore already visible in beta 4. Several of those features address long-standing pain points in startup performance, data modeling, and observability.
One of the most anticipated additions is explicit lazy imports, formalized in PEP 810. Large applications frequently pay a heavy cost at startup because every top-level import is executed immediately—even when many of the imported modules are never used in a given run. The new soft keyword lazy lets developers declare an import at module scope while deferring the actual loading until the name is first accessed. A simple example illustrates the behavior:
lazy import json
lazy from pathlib import Path
print("Starting up...") # neither module is loaded yet
data = json.loads('{"key": "value"}') # json loads here
p = Path(".") # pathlib loads here
The mechanism creates a lightweight proxy; the real module is loaded transparently on first use. If loading fails, the exception is raised at the point of use and the traceback includes both the access site and the original import statement, preserving debuggability. Global control is available through the -X lazy_imports option, the PYTHON_LAZY_IMPORTS environment variable, and runtime APIs such as sys.set_lazy_imports() and sys.set_lazy_imports_filter(). These facilities allow an application to make its own modules lazy while keeping third-party dependencies eager, or to enable laziness across the entire process without source changes. Restrictions exist—lazy imports are permitted only at module scope, and star imports or future imports cannot be lazy—but the design carefully balances convenience with predictability.
A second built-in that has been requested for years is frozendict (PEP 814). Parallel to the long-standing frozenset, it provides an immutable mapping that is hashable when its keys and values are hashable. Insertion order is preserved, yet equality ignores order. Because it is not a subclass of dict, code that previously relied on isinstance(obj, dict) may need modest updates, either to accept both types or to check against collections.abc.Mapping. Several standard-library modules already accept frozendict for serialization and related operations, and eval/exec accept it for the globals argument. The addition removes a common source of boilerplate in libraries that need immutable configuration or cache keys.
PEP 661 finally standardizes the sentinel pattern that developers have reinvented countless times. The new built-in sentinel type creates unique marker objects that preserve identity under copying, work cleanly in type expressions with the | operator, and can be pickled when they are importable by name. The result is a concise, language-supported alternative to the classic object() or module-level private constants.
Observability receives substantial attention. PEP 799 introduces a dedicated profiling package that reorganizes the existing tools and adds Tachyon, a high-frequency statistical sampling profiler. Unlike deterministic tracers that instrument every call, Tachyon periodically samples stack traces at rates up to one million hertz with virtually zero overhead. It can attach to a running process by PID, profile a script from the start, or capture a one-shot dump of every thread (or asyncio task). Wall-clock, CPU, and other modes are available, making production performance diagnosis far less invasive. Frame pointers are enabled by default (PEP 831), improving the quality of system-level stack traces for tools outside the Python runtime. Together these changes make Python processes more transparent to both language-level and OS-level profilers.
Performance work continues on multiple fronts. The experimental JIT compiler has been upgraded and now shows an 8–9 % geometric-mean improvement on x86-64 Linux relative to the standard interpreter, and a 12–13 % speedup on AArch64 macOS relative to the tail-calling interpreter. Official Windows 64-bit binaries switch to the tail-calling interpreter by default, and macOS installers enable free-threading support out of the box. These changes do not alter the language surface but reduce the cost of running the same code.
Language ergonomics also advance. PEP 798 allows unpacking (* and **) inside comprehensions, simplifying previously awkward constructions. UTF-8 becomes the default encoding for all I/O (PEP 686), ending the long-standing platform-dependent behavior that has tripped up countless cross-platform scripts. Improved error messages and additional color in the REPL and traceback output make interactive sessions and debugging more pleasant. On the typing side, TypedDict gains support for typed extra items, TypeForm annotations appear, and disjoint bases are recognized by the type system.
Package configuration receives a modernization via PEP 829, which introduces package startup configuration files as a cleaner successor to the traditional .pth mechanism. C-API improvements include a new PyBytesWriter for efficient bytes construction and a stable ABI for free-threaded builds, lowering the barrier for extension authors who want to support the free-threaded interpreter.
Beta 4 itself is not a feature release; it is a stabilization release. The 298 changes since beta 3 primarily close bugs, tighten build configurations, and polish documentation. The release notes emphasize that production use is still discouraged and that maintainers should wait for the first release candidate before publishing regular wheels. Pre-release wheels, however, are strongly encouraged so that downstream projects can test early.
Looking ahead, the schedule is tight but familiar. Release candidate 1 is expected on August 4, candidate 2 on September 1, and the final 3.15.0 on October 1. After that, bug-fix releases will appear approximately every two months for two years, followed by three additional years of security fixes. The five-year support window therefore extends to roughly October 2031.
For the Python community the immediate task is straightforward: download the beta, run the test suites of libraries and applications against it, and report anything that breaks. The combination of lazy imports, a native frozendict, a standardized sentinel, a modern sampling profiler, and measurable interpreter improvements makes 3.15 one of the more consequential releases in recent years. Beta 4 is the last broad invitation to help ensure that those improvements arrive cleanly when the final version ships in the autumn.
