New features in Python 3.14

Python 3.14 is the most consequential CPython release in years for teams that care about parallelism, safer string handling, and cleaner typing workflows. Whether you're on Fedora, Red Hat Enterprise Linux (RHEL), CentOS Stream, a Red Hat Universal Base Image (UBI) container, a Red Hat Hardened Image, or Red Hat OpenShift, this post tells you what changed in the language, where you can run it today, and what you need to change in your projects.

This post discusses the headline features in Python 3.14, then maps them to how Red Hat ships and supports the interpreter across the platforms you already use—including RHEL 10.2 and RHEL 9.8, both of which introduced the Python 3.14 stack in the same release wave (early 2026).

Where Python 3.14 fits in the Red Hat ecosystem

Python 3.14 is available across the full Red Hat stack. The delivery mechanism differs by platform:

• Fedora: The upstream community project, FedoraFedora Linuxnbsp;Linux is the fast-moving distribution where Red Hat and contributors integrate new upstream software before it lands in RHEL. Read What is Fedora? for how it relates to CentOS Stream and RHEL.
• CentOS Stream: CentOS Stream is the continuously delivered Linux distribution that sits between Fedora and RHEL it's the development platform where RHEL minor releases are built. Read What is CentOS Stream for more information, or read the project documentation.
• Red Hat Enterprise Linux (RHEL): The production foundation or deployments requiring a hardened security posture, long-term stability, and enterprise support. RHEL documentation describes the repositories.
• Red Hat Universal Base Image (UBI): Red Hat Universal Base Images (UBI) are OCI-compliant, freely redistributable container base images built from RHEL content, with their own license terms so you can build and ship containers outside Red Hat platforms. The Red Hat Ecosystem Catalog — UBI lists ubi9, ubi10, minimal, micro, and init variants. Read Types of container images to learn how UBI relates to other image types.
• Red Hat Hardened Images: Red Hat Hardened Images are a no-cost catalog of minimal, distroless-style container images built from Red Hat's pipeline—only what the application needs at runtime, with separate builder images for compile and dnf steps. For a product overview, read Hardened, ready, and no cost. For hands-on guidance, read Build and deploy secure minimal containers with Red Hat Hardened Images and Plan your image strategy. The image catalog is located at images.redhat.com.
• Red Hat OpenShift: The cloud-native application platform used to scale and orchestrate your containerized Python workloads.

Red Hat does not change the default system Python during a RHEL minor release cycle. On RHEL 10, the default remains Python 3.12 (python3 in BaseOS) for the full RHEL 10 lifecycle. Python 3.14 arrives as an additional AppStream channel package you install alongside the default—first in RHEL 10.2, alongside the same stack on RHEL 9.8. On RHEL 9, python3.14 is a dedicated application stream parallel to existing Python 3.9 and Python 3.12 choices. The CodeReady Linux Builder (CRB) channel also contains some Python content as noted below.

This AppStream model is intentional: platform stability for OS tooling, versioned choice for your applications.

Availability for FedoraFedora Linuxnbsp;Linux

• On the host: python3.14 RPMs in Fedora 43 and later (maintained in Fedora Packages — python3.14), including free-threading subpackages as they are packaged for each release.
• In containers: quay.io/fedora/python-314 and quay.io/fedora/python-314-minimal (listed in the s2i-python-container image matrix).

Fedora is the earliest place to prototype Python 3.14 features on a full desktop or server OS. Treat it as a preview of what will flow toward CentOS Stream and RHEL, not as a production support target unless your organization standardizes on Fedora directly.

Availability for CentOS Stream

• CentOS Stream 9: python3.14 packages in AppStream and related build tooling in CRB (see Stream 9 package sets).
• CentOS Stream 10: python3.14 in AppStream (for example, python3.14-3.14.x el10 builds), aligned with RHEL 10-oriented content.
• Container images on Quay: quay.io/sclorg/python-314-c9s, quay.io/sclorg/python-314-c10s, and matching -minimal variants as presented in the s2i-python-container table. This is useful for CI that must match Stream before RHEL minor releases ship.

Use CentOS Stream to validate workloads against upcoming RHEL behavior. Migrate production to RHEL 9.8 or RHEL 10.2 when you need subscription-backed errata and support.

RHEL 10.2 and RHEL 9.8: What is the same, what differs

Both minor releases ship python3.14 for application development, but the surrounding platform context differs:

If you standardize on Python 3.14 in 2026, decide whether the deployment target is RHEL 9.8 (long-running 9.x estates) or RHEL 10.2 (new 10.x adopters and 9.8→10.2 upgrades). Test on the same major RHEL you run in production.

Availability for Red Hat Universal Base Image (UBI)

UBI does not replace versioned Python runtime images. You have two common patterns:

1. Add Python 3.14 to a UBI base: Start from registry.access.redhat.com/ubi9/ubi or ubi10/ubi, enable UBI AppStream repositories, and dnf install python3.14 (the same RPM names as on RHEL when repositories are configured in the build).
2. Use RHEL Python runtime images: These are subscription-oriented application images, not generic UBI bases, documented in RHEL release notes and the catalog. For example:
   • registry.redhat.io/rhel9/python-314 (full)
   • registry.redhat.io/rhel9/python-314-minimal
   • registry.redhat.io/rhel10/python-314-minimal

Authenticate to registry.redhat.io as in Red Hat Container Registry authentication before pulling subscription-only images.

UBI fits custom Dockerfiles/Containerfiles you redistribute broadly, whilerhel9/python-314 fits entitled RHEL/OpenShift pipelines that need a maintained Python stack.

Availability for Red Hat Hardened Images

• Runtime: registry.access.redhat.com/hi/python:3.14 (minimal production image)
• Build stage: registry.access.redhat.com/hi/python:3.14-builder (includes package manager and tools for pip install, compiling extensions, and so on)
• FIPS environments: hi/python:3.14-fips and 3.14-fips-builder where required

Hardened Images target production security posture (small attack surface, rapid CVE remediation). Pair them with Python 3.14 when you want 3.14 language features without shipping a full UBI layer in the final image.

Practices that work everywhere

• Call python3.14 (not just an unversioned python3) in shebangs, Makefiles, and CI so you don't invoke Python 3.12 on RHEL 10 or 3.9 on RHEL 9.
• Keep project dependencies in a venv (python3.14 -m venv .venv) or container image, not mixed with system site-packages.
• On RHEL, subscribe and use official builds so you receive security errata targeting python3.14 RPMs for both -el9 and -el10_2 rather than various upstream compiles.

For Red Hat OpenShift, choose an image strategy explicitly:

• RHEL runtime images (rhel9/python-314): Documented in RHEL 9.8 and RHEL 10.2 release notes. Use with entitled registries.
• UBI-based builds: UBI plus python3.14 RPMs when you control the Containerfile and need redistribution-friendly bases.
• Hardened Images: Red Hat Hardened Images hi/python:3.14 when minimal production images matter most.

Avoid generic upstream-only Python images on cluster if your policy requires Red Hat-maintained errata paths.

Release highlights: Language and runtime

The official What's new in Python 3.14 documentation is the authoritative reference. Below is a developer-oriented tour focused on changes you are likely to feel in day-to-day Linux work.

Deferred evaluation of annotations (PEP 649, PEP 749)

Type annotations are no longer evaluated eagerly at function and class definition time. They are stored and evaluated when needed, which:

• Improves import and startup time for annotation-heavy codebases.
• Makes forward references work without from __future__ import annotations` in most cases.
• Introduces annotationlib for introspecting annotations as values, forward refs, or strings.

If you relied on annotations executing side effects at import time (uncommon but possible), audit those modules. Most Django, FastAPI, and dataclass-heavy apps benefit with no code changes.

Template string literals: t-strings (PEP 750)

t-strings use a t"..." prefix (like f-strings) but produce a Template object with separate static and interpolated parts instead of a single str. That enables safe, explicit processing—SQL builders, HTML escaping, structured logging—without regex-parsing f-string output.

from string.templatelib import Template, Interpolation# t-strings produce a Template object, not a string.# Pass it to a renderer that escapes each Interpolation value.user_input = "<script>alert('xss')</script>"tpl = t"<p>Hello, {user_input}</p>"# html = my_html_renderer(tpl) # renderer escapes user_input before inserting

For web and data services on RHEL or Red Hat OpenShift, t-strings are a pattern to adopt gradually: They shine when you own the rendering pipeline and want f-string ergonomics without f-string pitfalls.

Multiple interpreters in the standard library (PEP 734)

CPython has supported subinterpreters for years through the C API. Python 3.14 exposes concurrent.interpreters to Python code. Isolated interpreters can run in one process with less overhead than multiprocessing for some CPU-bound designs, and concurrent.futures.InterpreterPoolExecutor (in concurrent.futures) offers a familiar pool API.

Caveat for production on Linux: Many PyPI wheels with C extensions are still catching up to multi-interpreter and free-threaded builds. Test your dependency tree before betting a service on interpreter pools.

Free-threaded Python is supported upstream (PEP 779)

Python 3.13 introduced an experimental free-threaded build (GIL optional). Python 3.14 promotes the free-threading to officially supported status by the upstream community —a major step toward true multi-core parallelism in pure Python and in extensions that declare compatibility. While Python 3.14 is the first version where free-threaded Python is officially supported upstream, it is still considered optional and non-default.

Important: Free-threaded PythonPthon has not yet had sufficient testing against enterprise environments, so Red Hat has added it to the CRB repository for developers to work with until such time as full enterprise support can be guaranteed.

On Fedora and RHEL, free-threading is packaged separately. On RHEL 10.2, install python3.14-freethreading (standard and free-threading builds are split, similar to Fedora's packaging model). RHEL 9.8 also ships the python3.14 stack—confirm free-threading package names for your architecture in the 9.8 package manifest. That lets you opt in per application without changing the OS default (python3 remains Python 3.12 on RHEL 10, or Python 3.9 on RHEL 9).

When it helps: CPU-bound parallel workloads where threads previously serialized on the GIL.

When to wait: Libraries in your stack that are not yet tested on free-threaded builds (NumPy, pandas, and others are improving, but you should verify for your versions).

compression.zstd in the standard library (PEP 784)

Zstandard compression is available as compression.zstd, reducing the need for external zstandard bindings for many log archival, artifact cache, and data pipeline tasks—common in CI runners on CentOS Stream and Fedora.

Syntax and ergonomics

• PEP 758: except ValueError, TypeError: Allows catching multiple exception types without parentheses around the tuple.
• PEP 765: return, break, and continue that exit a finally block now emit a SyntaxWarning, so audit any finally blocks using these before upgrading.
• Improved error messages and syntax-highlighted REPL (including color in some standard-library CLIs) are small changes that add up during interactive debugging on remote RHEL hosts.

Asyncio introspection

Asyncio gains better introspection and debugging support, useful for microservices on OpenShift where you need to understand task stalls without attaching a heavy profiler.

Platform and packaging notes

• PEP 776: Emscripten is tier-3 supported (relevant if you target WASM toolchains from Fedora build roots).
• JIT (experimental) is included in all Windows and macOS official CPython 3.14 binaries (opt-in with PYTHON_JIT=1, disabled by default). Linux builds from Red Hat/Fedora follow distro packaging policy, so do not assume JIT is enabled in python3.14 RPMs until your release notes say so.
• PEP 761: PGP signatures discontinued for upstream CPython releases. Verify artifacts through your distro or Red Hat errata channels instead.

Feature deep dive: What Linux developers should try first

Here are some of the particulars you ought to address first.

Typing and application frameworks

If you maintain libraries or large apps on RHEL 9.8 or RHEL 10.2:

1. Remove redundant from __future__ import annotations where you only added it for forward refs.
2. Run your mypy/pyright CI job unchanged first, then explore annotationlib if you generate schemas from types.
3. Re-measure cold start for container entrypoints on OpenShift. Annotation deferral can save milliseconds to seconds on huge codebases.
4. On RHEL 10.2, remember dnf install python3-* targets Python 3.12 unless you version the package name (python3.14-* add-ons).

Concurrency on real hardware

Plan a benchmark branch: Standard python3.14 compared to python3.14-freethreading on RHEL 10.2 (or your 9.8 arch if free-threading RPMs are listed).Use the same workload, and the same dependency pins. Memory usage is often higher on free-threaded builds, but measure before changing production Deployment resource limits on Red Hat OpenShift.

Containers on Red Hat OpenShift

If you're running containers on Red Hat OpenShift, keep these points in mind:

• RHEL runtime image: registry.redhat.io/rhel9/python-314 or rhel9/python-314-minimal (see catalog — Python 3.14 Minimal).
• UBI + RPM: Build from ubi9/ubi or ubi10/ubi and install python3.14 when you need a custom image you can redistribute.
• Hardened Images: registry.access.redhat.com/hi/python:3.14-builder → hi/python:3.14 for minimal runtime (see build custom application images).
• S2I: s2i-python-container documents 3.14 images for RHEL 9 and 10, CentOS Stream 9 and 10, and Fedora.
• Security: Pin digests, and rebuild for Red Hat Security Advisory (RHSA) and Hardened Image catalog updates.

Data and platform engineering on RHEL 9.8 and RHEL 10.2

• Use compression.zstd for log shipping agents and artifact caches on hosts and in CentOS Stream 10 CI that gates RHEL 10.2 deploys.
• For UUID workloads, Python 3.14 adds uuid.uuid6(), uuid.uuid7(), and uuid.uuid8() (see RFC 9562), enabling time-sortable UUIDs, which are handy for database primary keys in distributed services without extra dependencies.
• Apply dnf update python3.14 on both releases to pick up CVE fixes using RHSA-backed advisories.

Porting from Python 3.12 or 3.13

Read Porting to Python 3.14 and the Python 3.14 changelog deprecations section. Priority checks for Red Hat platform teams:

On RHEL 9.8 and RHEL 10.2, stay on python3.14 RPM updates (3.14.1 → 3.14.4, and so on) through dnf update so you pick up CVE fixes without rebasing your own compile.

Support lifecycle and planning

Upstream CPython 3.14 follows the annual release cadence (PEP 602). Plan platform alignment roughly as:

• Fedora: Earliest consumption and widest package set (including free-threading splits).
• CentOS Stream 10: Validate stacks before locking RHEL 10.2 production baselines.
• RHEL 9.8: First 9.x minor with the python3.14 application stream—good for estates staying on RHEL 9 on Python 3.14 through 2029 when support for Python 3.14 application stream ends (RHEL 9 itself is supported through 2032). The python3.14-freethreading package is available in the CRB repository. Application Streams do not receive EUS or ELS coverage, so after May 2029, migrate to a newer Python AppStream.
• RHEL 10.2: First 10.x minor with python3.14 AppStream for new RHEL 10 deployments and 9.8 to 10.2 upgrades. System remains on Python 3.12, and python3.14-freethreading is available in the CRB repository.
• Red Hat OpenShift: Coordinate cluster version, builder image, and rhel9/python-314 image tags with your platform team; image updates track RHEL errata.

Conclusion

Python 3.14 brings deferred annotations, t-strings, standard-library subinterpreters, official free-threading, and compression.zstd—features that matter for modern services. Within the Red Hat ecosystem, you can adopt these features through python3.14 RPMs on the upstream Fedora project and CentOS Stream. For production, Red Hat Enterprise Linux 9.8 and 10.2 deliver Python 3.14 through AppStream (with free-threading available on RHEL 9.8 and 10.2 in CRB). This delivery allows you to install python3.14 for your workloads without replacing or impacting the system python3 that the base OS tools rely on (Python 3.12 on RHEL 10 and Python 3.9 on RHEL 9). This consistent footprint extends to containerized environments using Red Hat Universal Base Image (UBI), Red Hat Hardened Images (hi/python:3.14), and Red Hat OpenShift.

Start with a versioned virtual environment or a pinned container, run your test suite, and only then experiment with free-threading or interpreter pools. That sequence keeps your development predictable while still letting you use the most capable CPython release yet. By standardizing on official Red Hat Python builds across this pathway, you reduce operational overhead, maintain a supported, patched security baseline, and deploy with confidence on the platform you already trust.