RISC-V is now officially supported by CPython!

{"title_zh":"RISC-V 正式获得 CPython 支持：Python 开始进入更多芯片平台","body_zh":"# RISC-V 正式获得 CPython 支持：Python 开始进入更多芯片平台\n\nCPython 现在正式支持 RISC-V 平台。这项变化的意义不只是多了一个编译目标：使用 RISC-V 芯片的开发者、操作系统发行版和设备厂商，可以更有信心地构建、测试和分发标准 Python 运行时。对于 Python 生态来说，架构支持越接近上游，长期维护成本就越低。\n\n## “官方支持”具体改变了什么\n\nRISC-V 是一种开放指令集架构，已经被用于开发板、嵌入式设备、服务器和教学平台。过去，开发者可能需要依赖社区补丁、发行版的实验性构建，或者自行处理 CPython 在新架构上的编译问题。\n\n进入 CPython 的官方支持范围后，RISC-V 构建可以按照 CPython 的标准流程参与持续集成、回归测试和版本发布。这里需要区分两个概念：\n\n- CPython 能够在 RISC-V 上运行，不等于所有第三方包都已经提供 RISC-V 二进制 wheel。\n- 解释器架构支持稳定，不等于每个依赖的原生扩展都能立即通过编译。\n- 应用代码通常不需要针对 RISC-V 修改，但依赖 C、C++、Rust 或汇编优化的包仍需单独验证。\n\n因此，这是一项基础设施层面的进展。它为后续完善工具链、打包系统和第三方库兼容性提供了稳定起点。\n\n## 在 RISC-V 环境中构建并验证 CPython\n\n下面的示例假设你使用 Debian 或 Ubuntu 系的 RISC-V Linux 环境，并且已经安装了 Git、编译器和构建依赖。不同发行版的包名可能略有差异。\n\n先安装常见依赖：\n\nbash\nsudo apt-get update\nsudo apt-get install -y \\\n build-essential git pkg-config \\\n libssl-dev zlib1g-dev libbz2-dev libreadline-dev \\\n libsqlite3-dev libffi-dev liblzma-dev tk-dev \\\n uuid-dev\n\n\n获取 CPython 源码并编译一个独立安装目录：\n\nbash\ngit clone https://github.com/python/cpython.git\ncd cpython\n\n./configure \\\n --prefix="$HOME/.local/cpython-riscv64" \\\n --with-ensurepip=install\n\nmake -j"$(nproc)"\nmake install\n\nexport PATH="$HOME/.local/cpython-riscv64/bin:$PATH"\npython3 --version\npython3 -m pip --version\n\n\n验证解释器看到的架构以及基本运行能力：\n\nbash\npython3 - <<'PY'\nimport platform\nimport sys\n\nprint("Python:", sys.version.split()[0])\nprint("Machine:", platform.machine())\nprint("Implementation:", platform.python_implementation())\nassert platform.python_implementation() == "CPython"\nPY\n\n\n如果 platform.machine() 返回 riscv64，并且断言通过，就完成了一个最小的运行时检查。生产环境还应继续运行项目自己的测试套件，尤其要覆盖数据库驱动、加密库、科学计算库和其他带原生扩展的依赖。\n\n## 对 Python 项目维护者的影响\n\n项目本身通常不需要因为 RISC-V 而修改纯 Python 代码，但依赖发布策略值得检查。可以从下面几处开始：\n\n1. 查看依赖是否提供 RISC-V wheel；没有 wheel 时，构建流程是否能从源码安装。\n2. 检查 CI 中是否写死了 x86_64、amd64 或特定汇编优化。\n3. 对包含 C 扩展的项目，确认编译器、链接器和系统库版本要求。\n4. 避免在安装脚本中把平台判断写成“不是 x86 就拒绝”，除非确实存在功能限制。\n\n例如，构建脚本应优先使用 Python 和构建系统提供的平台信息，而不是只允许少数架构：\n\npython\nimport platform\n\nmachine = platform.machine().lower()\nif machine == "riscv64":\n print("Building the portable implementation for RISC-V")\nelse:\n print(f"Building for {machine}")\n\n\n这段代码只是一个示例。真正的项目应根据功能需求决定是否启用特定优化，并为不支持的路径提供清晰错误信息。\n\n## 采用前要关注的边界\n\n官方支持会降低解释器层面的不确定性，但不会自动解决整个生态的兼容性问题。团队评估 RISC-V 部署时，可以按以下顺序推进：\n\n- 先用标准 CPython 运行纯 Python 服务和测试。\n- 再逐项安装带原生代码的依赖，记录源码构建时间和系统库要求。\n- 为关键依赖建立可重复的 wheel 或系统包构建流程。\n- 将 RISC-V 纳入 CI，至少覆盖启动、单元测试和核心业务路径。\n- 对性能敏感代码分别测量，不要直接假设 x86 优化策略可以原样迁移。\n\nCPython 的正式支持让 RISC-V 从“需要额外维护的实验平台”更接近“可以纳入常规工程流程的目标平台”。接下来真正决定使用体验的，将是发行版、包索引、构建工具以及第三方原生扩展能否同步跟上。对于希望扩大硬件选择范围的团队，现在适合开始做依赖盘点和小规模验证。","title_en":"CPython Officially Supports RISC-V: What Python Developers Need to Know","body_en":"# CPython Officially Supports RISC-V: What Python Developers Need to Know\n\nCPython now officially supports RISC-V platforms. This is more than an additional build target: developers, Linux distributions, and hardware vendors using RISC-V can build, test, and distribute the standard Python runtime with greater confidence. Upstream architecture support also reduces long-term maintenance work across the ecosystem.\n\n## What official support changes\n\nRISC-V is an open instruction-set architecture used in development boards, embedded systems, servers, and education platforms. Before upstream support, teams often had to rely on downstream patches, experimental distribution builds, or their own fixes for CPython compilation issues.\n\nWith RISC-V in CPython’s official support scope, builds can follow the normal CPython workflows for regression testing and release maintenance. Three boundaries are important: \n\n- CPython running on RISC-V does not mean every third-party package already publishes a RISC-V binary wheel.\n- A stable interpreter port does not mean every native extension will compile immediately.\n- Most application code should remain portable, but packages using C, C++, Rust, or assembly optimizations still need validation.\n\nThis is therefore an infrastructure milestone. It provides a stable base for improving toolchains, packaging, and third-party compatibility.\n\n## Build and verify CPython on RISC-V\n\nThe following example assumes a Debian- or Ubuntu-based RISC-V Linux system with Git, a compiler, and the usual build dependencies available. Package names may differ across distributions.\n\nInstall common dependencies:\n\nbash\nsudo apt-get update\nsudo apt-get install -y \\\n build-essential git pkg-config \\\n libssl-dev zlib1g-dev libbz2-dev libreadline-dev \\\n libsqlite3-dev libffi-dev liblzma-dev tk-dev \\\n uuid-dev\n\n\nClone CPython and install it into an isolated prefix:\n\nbash\ngit clone https://github.com/python/cpython.git\ncd cpython\n\n./configure \\\n --prefix="$HOME/.local/cpython-riscv64" \\\n --with-ensurepip=install\n\nmake -j"$(nproc)"\nmake install\n\nexport PATH="$HOME/.local/cpython-riscv64/bin:$PATH"\npython3 --version\npython3 -m pip --version\n\n\nThen verify the interpreter and reported machine type:\n\nbash\npython3 - <<'PY'\nimport platform\nimport sys\n\nprint("Python:", sys.version.split()[0])\nprint("Machine:", platform.machine())\nprint("Implementation:", platform.python_implementation())\nassert platform.python_implementation() == "CPython"\nPY\n\n\nA result of riscv64 from platform.machine() plus a passing assertion gives you a minimal runtime check. Production validation should also run the project test suite, especially around database drivers, cryptography, scientific packages, and other native extensions.\n\n## What project maintainers should check\n\nPure Python code usually does not need RISC-V-specific changes, but dependency distribution deserves attention. Start with these checks:\n\n1. Determine whether dependencies publish RISC-V wheels and whether source installation is practical when they do not.\n2. Search CI and build scripts for assumptions such as x86_64, amd64, or mandatory assembly optimizations.\n3. Verify compiler, linker, and system-library requirements for native extensions.\n4. Avoid rejecting every non-x86 platform in installation logic unless the project has a real functional limitation.\n\nFor example, a build script can use platform information while keeping a portable path available:\n\npython\nimport platform\n\nmachine = platform.machine().lower()\nif machine == "riscv64":\n print("Building the portable implementation for RISC-V")\nelse:\n print(f"Building for {machine}")\n\n\nThis is only a minimal example. A real project should select optimizations based on measured capabilities and provide a clear error when a required feature is unavailable.\n\n## A practical adoption checklist\n\nOfficial support removes uncertainty at the interpreter layer, but it does not solve compatibility across the entire Python ecosystem. A sensible rollout is incremental:\n\n- Run pure Python services and tests on standard CPython for RISC-V.\n- Install native dependencies one by one and record source-build time and system-library requirements.\n- Create reproducible wheel or distribution-package builds for critical dependencies.\n- Add RISC-V to CI, covering startup, unit tests, and core business paths.\n- Benchmark performance-sensitive code instead of assuming x86 optimization strategies transfer unchanged.\n\nCPython’s official support moves RISC-V closer to a normal engineering target rather than a platform requiring a separate interpreter maintenance effort. The next user-experience gains will depend on distributions, package indexes, build tools, and native extensions catching up. For teams interested in a broader hardware portfolio, this is a good point to inventory dependencies and begin a focused compatibility pilot.","seo_description_en":"CPython now officially supports RISC-V. Learn what this changes, how to build it, and how to prepare Python projects for native extensions and CI."}