Cal Paterson 在 2021 年写了一篇后来成为经典的博客：《An Oral History of Bank Python》。五年后，这篇文章再次登上 Hacker News 首页（38 分），评论区的新一轮讨论揭示了一个耐人寻味的变化：五年前读者把这当猎奇故事看，五年后他们发现自建 Python 生态的冲动在自己的公司也开始冒头了。
Bank Python 不是一个贬义词。它是 Paterson 用来描述一类现象的名字：在大型投资银行的 IT 部门里，存在着一整套与开源 Python 生态几乎完全隔离的内部 Python 系统。这些系统有自己的 ORM（不是 SQLAlchemy）、自己的调度器（不是 Airflow）、自己的包索引（不是 PyPI）、自己的 IDE 集成（不是 VSCode）。它们用 Python 语法写，但活在一个外人看不到的平行宇宙里。
为什么会有另一个 Python 宇宙
Paterson 的解释链很简洁。
第一步：这些系统大多诞生于 2005-2012 年。那个时期的 Python 生态和今天不一样——asyncio 不存在，pandas 还在早期，高性能 Web 框架处于战国时代。银行的量化分析师（Quants）和交易台（Trading Desk）开发者需要用 Python 快速写交易逻辑，但开源工具在延迟要求上不够用，功能上也不够垂直。于是他们自己写。
第二步：这些自研工具一旦跑起来，就积累了自己的用户群、自己的 Stack Overflow（内部 Wiki）、自己的「最佳实践」。新员工入职，先学这套内部系统，而不是先学开源 Python。到了这一步，切换回开源工具的成本已经巨大——开源工具本身够好，但内部系统内化了太多业务逻辑。你没法用 SQLAlchemy 替换内部 ORM，除非你把十五年来所有交易策略里硬编码的 ORM 调用也改了。
第三步：这些工具在银行内部变成了实际上的基础设施。基础设施的悖论是：你对它的依赖越深，你越不能碰它。一个运行了十年的调度器可能用的是 Python 2.7、部署在一台物理机器上，但没人敢迁移——因为全公司的每日风险报告都依赖它。
内部 ORM 的幽灵
银行内部 ORM 是 Paterson 全文最精彩的分析对象之一。开源 Python 的 ORM 方案（SQLAlchemy、Django ORM）有两个特点：一是用 Python 类映射到数据库表，二是查询用 Python 方法链或 DSL 表示。这个设计模式要求你理解两套东西——Python 的模型层和数据库的 SQL 层。
银行的做法不同。他们的 ORM 不是「对象-关系映射」，更接近「表-字典映射」——直接暴露数据库表的结构，查询接口是类 SQL 的函数调用。Paterson 把这个称为「反 ORM」：它不做抽象，它只做薄封装。你在代码里写的仍然是 SELECT * FROM positions WHERE book = 'EQ-ASIA'，只是包在一个 Python 函数里。
为什么这样设计？因为量化分析师不需要 ORM 提供的面向对象抽象——他们需要的是用最快的速度把 SQL 查询的结果变成 Python 里的 dict 或 DataFrame，然后跑运算。对象模型的延迟和内存开销在这个场景下全是负担。
但这个设计也埋下了一个问题：当业务逻辑足够复杂之后，SQL 字符串拼接遍布代码库，没有类型检查，没有任何抽象给重构提供支撑。这在 2010 年不算致命问题，在 2026 年就成了无法忽视的债务——任何一个新人接手这些代码，都需要先学会「这些 SQL 里哪些是历史遗留的废弃物，哪些还在线上跑」。
内部包索引的文化隔离
银行 Python 生态还有一个几乎看不见但非常重要的特征：内部 PyPI。
投资银行的网络安全策略通常极其保守。开发者的机器不能直接访问公网，或者只能通过严格的代理访问。这意味着你没法 pip install 任何东西——所有依赖必须从内部包索引安装。内部索引里的每个包都经过了安全团队的审查和批准。
这产生了一个副作用：版本冻结。一旦一个包的某个版本通过了审查，更新到新版本就需要重新走流程。这个流程通常以月为单位。结果就是银行内部的 Python 包版本普遍滞后开源生态 2-5 年。
短期的代价是安全。长期的代价是技能贬值。当一个银行内部的 Python 开发者在 2026 年还在用 2019 年版本的 NumPy 写量化模型，他学到的是一个被时间胶囊封存的 Python。如果他想离开银行去科技公司，面对的困难是「你的技能已经是五年前的版本」。
HN 评论区的新角度
2021 年原文下的 HN 讨论（864 分、325 条评论）和 2026 年重新浮上首页的讨论之间有一些微妙的变化。
五年前，评论区主要集中在「银行的 IT 系统有多烂」——各种关于 COBOL、Excel 宏和 Windows XP 的笑话。五年后的讨论里，出现了更多自我反省的声音。一条评论写道：「我工作的 SaaS 公司现在也有了自己的内部 ORM、内部调度器、内部登录框架。我们嘲笑银行，但我们在做完全一样的事情。只是规模小了一两个数量级。」
另一条高赞评论给出了一个更尖锐的判断：「自建基础设施在创业公司叫技术选型，在银行叫技术债。区别不在于代码质量，在于你是否有能力在五年后完整迁移出去。」
这句话几乎可以概括 Bank Python 口述史的全部核心洞察：问题不在于自研——自研很多时候是正确决策。问题在于自研的产物一旦沉淀为基础设施，你是否有退出策略。银行没有。大多数公司也没有。
本文基于 Cal Paterson 的原创博客及相关 HN 讨论整理。Bank Python 作为一个未出版的「口述史」，其素材来自 Paterson 在伦敦投行圈的数年从业经验和多方访谈。