CPython now officially supports RISC-V: what PEP 11 tier 3 actually guarantees

What actually changed in CPython's RISC-V support

On 24 August 2026, CPython core developer Stan Ulbrych announced that RISC-V is now an officially supported CPython platform at PEP 11 tier 3. The target triple listed in the PEP is riscv64-unknown-linux-gnu, covering both the glibc/gcc and glibc/clang combinations, with Stan Ulbrych and Emma Smith signed up as platform contacts.

The word doing the work in that sentence is officially. CPython has compiled and run on RISC-V hardware for years. What changed is that the platform now sits inside a written support policy, with a named maintainer and a buildbot the core team watches. Before this, RISC-V was in the same bucket as any other unsupported architecture: the code might work, but nobody on the core team owed you anything if it stopped working.

Two things made the promotion possible, and both are worth understanding if you are evaluating RISC-V for a Python workload. First, the RISE Project donated real RISC-V machines to run CPython buildbots, so failures are now detected on hardware rather than under emulation. Second, the packaging ecosystem quietly solved the harder problem first — which we get to below.

What tier 3 promises, and what it does not

PEP 11 defines three support tiers with genuinely different guarantees. Reading tier 3 as "Python supports RISC-V now" overstates it in a way that will bite you during a release cycle.

So the honest reading of tier 3: a RISC-V regression can land in main, survive the beta cycle, and ship in a released Python. Nothing in the policy stops it. Buildbots also run after a patch merges, which is why the CPython team is now working with RISE to bring RISC-V into pre-merge CI through the RISE RISC-V Runners initiative — that is the change that would actually shorten the window where a regression can slip through.

Tier 3 keeps company with iOS on device, 32-bit Raspberry Pi OS, s390x, FreeBSD and Emscripten. That is the right mental model: supported enough to file a bug against and expect someone to look, not supported enough to skip your own testing.

Can you pip install on riscv64 today?

This is the question that actually determines whether RISC-V is viable for your project, and it has a more encouraging answer than the CPython news suggests — because the packaging layer got there roughly a year ahead of PEP 11.

The practical result is that projects have been shipping riscv64 wheels to PyPI ahead of the CPython announcement — lxml, uv, maturin and ninja among the early ones — and RISE has published riscv64 builds of the harder scientific stack, including numpy and, as of 18 August 2026, PyTorch wheels tagged manylinux_2_39_riscv64 built on real RISC-V hardware rather than under QEMU.

The caveat that matters for planning: coverage is uneven. A pure-Python dependency tree will install without drama. A tree with a dozen compiled extensions will have one or two packages with no riscv64 wheel, and pip will fall back to building from source on a machine that is usually slower than your x86 CI. Budget for that before you commit.

The pip version trap that silently gives you old packages

This is the failure mode most likely to waste your afternoon, and it produces no error message.

Before manylinux riscv64 tags existed, a handful of packages were published with the plain linux_riscv64 platform tag. Those files are still on PyPI and in mirrors. A pip older than 24.1 does not recognise manylinux_2_39_riscv64, so it skips the current wheel, matches the old plain-tagged one, and installs it. You get a successful install and a package that may be several versions behind, with no warning that a newer wheel was sitting right there.

Check the interpreter's own view of what it will accept before you debug anything else:

python3 -m pip --version
python3 -c "import sysconfig; print(sysconfig.get_platform())"
python3 -m pip debug --verbose | grep -i riscv

You want pip 24.1 or newer, a platform of linux-riscv64, and manylinux_2_39_riscv64 present in the compatible tag list. If the manylinux tags are missing, upgrade pip first and re-run your install — do not start filing bugs against the package.

Building and testing CPython on RISC-V hardware

Tier 3 explicitly asks for user feedback, and the core team's request is specific: build it, run your own workloads and test suites on it, and report what breaks. If you have access to a board or a cloud RISC-V instance, the loop is the standard CPython one.

git clone https://github.com/python/cpython.git
cd cpython
./configure --with-pydebug
make -j"$(nproc)"
./python -m test -j0

Two practical notes from the shape of tier 3. Run the full test suite rather than a smoke test, because the failures worth reporting are the architecture-specific ones — alignment, floating point edge cases, ctypes calling conventions — and those live in corners a smoke test never reaches. And build with both toolchains if you can: PEP 11 lists gcc and clang separately for riscv64 for a reason, and a bug that only appears under one of them is exactly the kind of thing a single buildbot configuration can miss.

If you maintain a package with C extensions and you want riscv64 wheels, the work is now mostly configuration rather than porting: enable the riscv64 architecture in cibuildwheel and let it use the manylinux riscv64 image. The slow part is not the setup, it is the build time on the emulated or lower-clocked hardware most CI runners give you.

When targeting RISC-V is actually worth it

Tier 3 is a real milestone, but it is not a signal to move production workloads. Here is how I would frame the decision.

• Worth doing now: you ship a library with C extensions and want to stop being the reason someone's RISC-V build fails. Adding the architecture to cibuildwheel is cheap and the ecosystem is ready to receive the wheels.
• Worth doing now: you are running Python on embedded or edge hardware where the ISA licensing cost is a real line item. This is the case where RISC-V's open ISA is the point, not a curiosity.
• Worth prototyping: you have a compute-light backend service and want optionality on hardware suppliers. Test it, measure it, keep x86 as the deployment target until wheel coverage for your exact dependency tree is complete.
• Not yet: anything where a regression shipping in a Python point release would be a production incident. Tier 3 has no response SLA and does not block releases. That is a policy fact, not pessimism.

The pattern here is one we hit constantly on migration work: the language runtime is rarely the blocker. The blocker is the long tail of compiled dependencies, and the honest way to find out how long that tail is for your project is to run your real requirements.txt against the target and count the source builds. If that audit is the sort of thing you would rather hand to someone, it is close to what we do on custom software and platform migration projects.

The longer-term direction is clear enough from the announcement: pre-merge CI first, tier 2 as the stated goal, and architecture-specific optimisations after that. RISC-V is on a trajectory. It is just earlier on it than a headline reading "officially supported" suggests.

Deciding whether your stack can move

If you are weighing a platform move — RISC-V, ARM, or off a legacy runtime entirely — the useful first artifact is not a benchmark, it is a dependency audit that tells you which packages have no binary for your target and what building them costs. We scope that kind of work directly: tell us what your stack looks like and what you are trying to move to, and you will get a straight answer on effort rather than a proposal deck.