prylint 0.4.2 在 2026 年 6 月 19 日发布到 PyPI。
这个项目有一个很反常的目标：它不是想把 pylint 做得更“现代”，而是想把 pylint 4.0.5 的行为复刻到足够像，让现有 CI 尽量察觉不到执行器换了。
这比“Rust 重写 Python 工具”更有意思。Python 生态里已经有 Ruff 这样的高速检查器。prylint 要赌的不是新规则，而是旧规则能不能跑得更快，还不惊动旧流程。
我更在意的是这一点：如果它真能稳定做到差分一致，它的价值会落在大型 Python 仓库的 CI 成本上，而不是普通开发者本地少等几秒。
它重写的是 pylint 的行为，不是另起一套规则
prylint 0.4.2 对齐的是 pylint 4.0.5 和 astroid 4.0.4。
项目说明里的关键说法是“bug-for-bug port”。换句话说，它追求的不是“结果差不多”，而是输出文本、消息顺序、退出码、评分页脚等可观察行为尽量和 pylint 字节级一致。
这件事对工程团队很现实。很多公司不是单纯在命令行里看 pylint 报错，而是把它接进 CI、质量门禁、报告解析和历史阈值里。换工具最怕的不是快不快，而是规则变了、分数变了、退出码变了。
| 对比项 | pylint | Ruff | prylint 0.4.2 |
|---|---|---|---|
| 核心定位 | 既有 Python 静态检查工具 | 高速 linter，覆盖多类规则 | pylint 兼容执行器 |
| 主要价值 | 规则成熟，生态已有使用惯性 | 快，工具链整合度高 | 尽量不改现有 pylint 流程 |
| 迁移风险 | 无迁移，但慢 | 规则与输出可能不同 | 目标是差分一致，但有例外 |
| 版本边界 | 随 pylint 演进 | 自有实现路线 | 锚定 pylint 4.0.5 / astroid 4.0.4 |
这里要划清一条线：prylint 不是官方 pylint 项目，也不是 Pylint 团队宣布重写。现有材料显示，作者是 Adam Raudonis。
这也决定了它的评估方式。不要把它当成“pylint 的下一代”。更合适的看法是：它能不能成为 pylint 4.0.5 的低成本替代执行器。
85×很亮眼，但只能按基准条件读
prylint 给出的性能数据很激进。
项目方称，在 Apple M 系列机器、单线程、对比 pylint 4.0.5 的条件下，prylint 的中位数提速约 85×。部分仓库最高约 2300×。
验证范围也不算小：52 个生产代码库，约 6.5 万个 Python 文件，包括 django、numpy、pandas、sympy、home-assistant、sqlalchemy、twisted、scikit-learn 等。
几个典型数字能说明问题：
| 仓库 | pylint 4.0.5 | prylint 0.4.2 | 项目方给出的提升 |
|---|---|---|---|
| black | 26.7 小时 | 41 秒 | 约 2328× |
| django | 1524 秒 | 10.1 秒 | 约 150× |
| pandas | 1009 秒 | 14.2 秒 | 约 71× |
| 整体中位数 | — | — | 约 85× |
这些数字足够说明方向：pylint 在大仓库里确实可能是 CI 里的慢环节。
但它们不能直接外推到所有项目。机器架构、启用规则、配置文件、代码结构都会影响结果。项目方也明确给出限制：仍有 LIMITATIONS.md 记录的例外，以及部分 nondeterminism 场景。
还有一个细节值得看。prylint 目前坚持单线程，并不是因为多线程没有吸引力，而是为了复刻 astroid 对顺序敏感的全局缓存行为。
这说明它的优先级很清楚：先像，再快。快是结果，不是唯一目标。
大仓库可以试，小项目没必要急
最该行动的是两类人。
一类是维护大型 Python 代码库的工程团队。尤其是每天多次跑全量 pylint、CI 队列经常被静态检查拖住的团队。对他们来说，几十分钟变几十秒，不只是体验问题，还会影响合并等待时间、机器占用和质量门禁的执行意愿。
另一类是依赖 pylint 输出做自动化处理的团队。比如脚本读取退出码、解析评分页脚、统计消息顺序，或者用历史分数做阈值。这类团队不会轻易换成规则不同的工具，但会愿意测试一个“尽量像 pylint 的更快执行器”。
更稳的做法不是马上替换。
可以先在 CI 里跑一段影子模式：pylint 仍作为准绳，prylint 只做对照。重点比对四件事：输出文本、消息顺序、退出码、评分页脚。
如果项目依赖复杂配置、自定义扩展、边缘语法，或者已经准备跟进未来 pylint 行为，就更要保守。prylint 0.4.2 对齐的是 pylint 4.0.5，不代表天然兼容未来版本。
小项目和个人开发者不用急。若 pylint 本来只跑几秒，换工具省下的时间有限，反而要承担 Beta 状态和例外场景带来的不确定性。观望比折腾更划算。
门槛也要说清楚。prylint 虽然不要求安装 pylint 和 astroid，但仍需要 PATH 上有 Python 3.9+，用于复刻模块解析路径和 CPython 的语法错误信息。PyPI 上的项目状态是 Beta，许可证为 GPL-2.0-or-later。
接下来要看的不是它还能不能刷出更夸张的速度数字，而是三个硬变量：
- 能不能跟上 pylint 后续版本，而不是长期停在 4.0.5。
- LIMITATIONS.md 里的已知例外会不会减少。
- 真实公司仓库在历史配置、插件依赖和边缘代码下，差分是否仍然稳定。
如果这三关过不去，prylint 只是一次漂亮的工程实验。若能过，它才有机会进入大型 Python 项目的日常 CI。