Python Adds Official RISC-V Support: What Developers Can Use Now and What Still Needs Work

• CPython officially recognized RISC-V as a Tier 3 supported platform on August 24, 2026.
• Developers can build and test CPython on RISC-V hardware, but package availability and platform-specific compatibility still vary.
• The Python core team is working toward better continuous integration and may eventually pursue Tier 2 support.

CPython now officially supports RISC-V

CPython, the reference implementation of Python, now officially recognizes RISC-V as a Tier 3 platform. The Python core team announced the change on August 24, 2026, after months of work improving builds, testing, and hardware support.

That’s a meaningful step for developers using open instruction set hardware. It means RISC-V is no longer treated simply as an experimental port maintained outside the core project. CPython now has an official support status, ongoing testing infrastructure, and a clearer path for reporting and fixing platform-specific problems.

It doesn’t mean every Python package is ready for RISC-V or that prebuilt wheels are available for every distribution. The immediate change is about CPython itself: the interpreter can be built, tested, and maintained as an officially supported platform.

What Tier 3 support means

CPython’s platform policy, defined in PEP 11, uses support tiers to describe the level of testing and maintenance a platform receives.

For RISC-V users, Tier 3 is best understood as an official starting point rather than a promise of identical coverage with mainstream x86 or Arm systems. The core team has acknowledged the architecture and is prepared to address relevant issues, but RISC-V failures do not carry the same release-blocking weight as failures on higher-tier platforms.

How CPython reached this milestone

The announcement credits community contributors, real-hardware testing, and the RISE Project, which provided RISC-V machines for CPython buildbots. Those buildbots give the project a way to compile CPython and run tests on actual RISC-V systems instead of relying only on emulation or cross-compilation.

That distinction matters. Architecture-specific issues can involve the compiler, operating system, C library, hardware behavior, or assumptions hidden in low-level code. Testing on physical systems gives maintainers a better chance of finding problems that don’t appear on ordinary developer machines.

The work also included build improvements, bug fixes, and reviews needed to bring RISC-V support to the standard expected for inclusion in CPython’s official platform policy.

What this means for developers

You can build CPython on RISC-V hardware

Developers with compatible RISC-V systems can now treat CPython as an officially supported source build target rather than an unofficial port. The normal Unix-style build process still applies: configure the source tree, compile it, run the test suite, and install the result.

CPython’s build documentation lists a C11 compiler, thread support, and IEEE 754 floating-point support among the general requirements. Optional standard-library modules may also need additional development libraries installed on the system.

Read the CPython build and configuration documentation ↗

Because RISC-V hardware and Linux distributions vary, a successful interpreter build doesn’t guarantee that every optional module or third-party dependency will work without additional configuration.

Get the official CPython source and build documentation ↗

Testing is now more valuable

The Python team is asking people with access to RISC-V hardware to run real workloads and test suites, then report anything that breaks. That feedback can expose problems in areas such as native extensions, filesystem behavior, threading, numerical code, packaging, and compiler interactions.

Report a CPython issue ↗

For teams developing software that may eventually run on RISC-V devices, this is a good time to add architecture-specific testing instead of waiting until deployment. Even a small test job can reveal assumptions about pointer size, instruction availability, alignment, atomic operations, or platform naming.

Package compatibility will take longer

Official CPython support does not automatically make the entire Python ecosystem RISC-V-ready. Many packages are pure Python and should be portable, but packages with C, C++, Rust, Fortran, or other native components may need their own build fixes and release work.

Prebuilt wheel availability is also a separate issue. A package may support RISC-V in principle while still requiring users to compile it locally because a compatible wheel has not been published for their operating system and Python version.

That means developers should check each important dependency rather than assuming that a working CPython build guarantees a working application stack.

What the Python team plans to do next

The next major goal is better testing through the RISE RISC-V Runners initiative. The project is investigating how to bring RISC-V more directly into CPython’s continuous integration system.

Buildbots generally run after a change has been merged, while continuous integration can provide feedback earlier in the development process. Earlier testing should help maintainers catch RISC-V-specific regressions before they become part of the main branch.

The longer-term ambition is to pursue Tier 2 status. That would require stronger ongoing commitments, including reliable buildbot coverage and clearly designated core developer support. The Python team has not announced a date for that promotion.

What this does not mean yet

• It does not mean every Linux distribution offers an official prebuilt RISC-V Python package.
• It does not mean all third-party Python packages publish RISC-V wheels.
• It does not guarantee identical performance across different RISC-V processors.
• It does not promise that RISC-V failures will block CPython releases in the same way as Tier 1 or Tier 2 failures.
• It does not mean architecture-specific optimizations are already complete.

The Python team says there is still work to do on performance, package support, testing coverage, and infrastructure. For now, the practical status is straightforward: CPython officially supports RISC-V at Tier 3, and real-world users can help determine how quickly that support matures.

Helpful Links

• RISC-V is now officially supported by CPython – Read the Python core team’s announcement and details about current testing and future plans.
• PEP 11: CPython platform support – Review the definitions and expectations for Tier 1, Tier 2, and Tier 3 platform support.
• Python Developer Guide: Porting and platform support – Learn how CPython platform support, ports, buildbots, and platform-specific maintenance are handled.
• CPython source code – Get the CPython source tree and follow current development work.
• Python source releases – Download official CPython source release archives.
• Configure Python – Official page referenced in the article.
• CPython issue tracker – Official page referenced in the article.

Frequently Asked Questions

Q. Is RISC-V now a fully supported Python platform?

A. RISC-V is now an officially supported CPython platform at Tier 3. That is formal support, but it provides lighter testing and maintenance commitments than Tier 1 and Tier 2 platforms.

Q. Can I install Python on any RISC-V computer?

A. Not necessarily. CPython can be built for supported RISC-V environments, but the exact result depends on the operating system, compiler, C library, hardware, and available development dependencies.

Q. Will Python packages automatically work on RISC-V?

A. No. Pure-Python packages are generally easier to use, while packages with native extensions may need RISC-V-specific fixes or local compilation. Prebuilt wheel availability will vary by package and operating system.

Q. When will RISC-V receive Tier 2 CPython support?

A. The Python team has expressed interest in working toward Tier 2 support, but no promotion date has been officially announced.