UXVII
首页 标签 关于 |

微软解散 Faster CPython 团队：Python 性能何去何从？

发表于 2025-05-17
 更新于 7 日内 许可证 CC BY-NC-SA 4.0 pythonmicrosoft

目录

微软宣布解散 Faster CPython 团队，本文由 Google Gemini Deep Research 生成

Python，作为当今最受欢迎的编程语言之一，其简洁的语法和庞大的生态系统赢得了全球开发者的青睐。然而，性能问题，特别是与 C/C++ 等编译型语言相比时的速度，一直是 CPython（Python 的官方和最常用实现）用户和开发者关注的焦点。在提升 Python 性能的漫漫征途中，微软曾一度扮演了关键的推动者角色，其资助的 Faster CPython 团队更是取得了令人瞩目的成就。然而，一则突如其来的消息震动了整个 Python 社区：微软决定解散这支专注于提升 CPython 性能的核心团队。这一决策不仅让许多人错愕，更引发了关于企业赞助开源项目、技术专家价值以及 Python 未来性能走向的深刻讨论。本文旨在评估微软此举，探讨其潜在影响，并展望 CPython 性能优化的未来之路。

戛然而止：微软解散其备受赞誉的 Faster CPython 团队

晴天霹雳：项目支持取消，团队成员离散

2025 年 5 月，微软取消对 Faster CPython 项目支持并解散大部分团队成员的消息迅速传开 [1]。微软首席软件工程经理、CPython 核心开发者 Mike Droettboom 在其社交媒体上确认了这一消息，并对受影响的团队成员表达了深切的同情与惋惜 [1]。这一变故不仅意味着一个备受期待的性能提升计划可能戛然而止，更让 Python 社区失去了一支由顶尖专家组成的、专注于核心优化的强大力量。

根据 Python 核心开发者 Brett Cannon 发布的消息，此次裁员波及了多位 Faster CPython 团队的核心成员，包括项目的技术负责人和发起人 Mark Shannon，以及资深核心开发者 Eric Snow 和 Irit Katriel [3]。这些名字在 Python 社区中如雷贯耳，他们的离去无疑是 CPython 性能优化领域的一大损失。Faster CPython 团队是微软一项高调公开支持的计划，其突然终结令社区倍感意外和不解。

时机与背景：微软大规模裁员浪潮中的一朵浪花

此次针对 Faster CPython 团队的调整并非孤立事件，而是微软全球大规模裁员计划的一部分。据报道，微软宣布了全球范围内约 3% 的员工裁减，影响近 7000 个职位 [2]。在其总部所在的华盛顿州，就有近 2000 个职位被削减，其中软件工程岗位受到的冲击尤为严重，仅雷德蒙德总部的软件工程师职位就减少了 817 个 [2]。

裁员波及了微软的多个部门，包括 TypeScript 和 Azure SDK 等团队 [2]，显示出这是一次广泛的成本削减或战略调整行动。令人唏嘘的是，许多团队成员是在前往匹兹堡参加 PyCon（Python 开发者大会）及其语言峰会的途中收到的裁员通知 [2]。Mike Droettboom 透露的这一细节，不仅凸显了事件的突然性，也在某种程度上反映了企业决策在执行层面可能存在的对个体情感和社区影响的考量不足。

这种时机选择，将一项商业决策转变成了更具个人色彩和公众感受的冲击。这背后可能反映了高层企业决策与基层执行及社区影响之间的脱节，或者仅仅是严格遵循预定裁员时间表，而未充分顾及此类重大外部活动。

更深层次来看，团队的解散不仅仅是失去了几位独立的贡献者，而是瓦解了一个已经形成了协同知识体系和明确使命的战斗集体 [7]。这个团队汇集了如 Mark Shannon、Python 之父 Guido van Rossum、Eric Snow 和 Irit Katriel 等杰出人才 [7]，他们的紧密协作和微软的资金支持使得 Python 3.11 等版本取得了显著的性能提升 [9]。如今，这种高度集中的专业力量和研发势头被迫中断，未来即便这些专家以个人身份继续贡献，也很难在短时间内复制这样一个有组织、有资助的专注环境。

探寻背后：解读微软此举的可能动机

微软的官方说辞：模糊且标准

对于此次裁员，微软官方给出的解释一如既往地标准且模糊：“我们持续进行组织变革，以确保公司在动态市场中取得最佳成功定位” [2]。这种声明几乎没有提供任何针对 CPython 团队被裁的具体原因。微软首席财务官 Amy Hood曾在 4 月份提及要“通过减少管理层级来提升敏捷性” [2]，公司也表示此次裁员的重点之一是削减管理人员 [5]，但实际情况是大量软件工程师受到了影响 [2]。这类通用性声明在企业裁员时屡见不鲜，往往掩盖了更复杂或具体的原因，从而引发外界的种种猜测。

AI 浪潮下的考量：一把双刃剑？

微软正斥巨资投入人工智能和数据中心建设 [2]。公司首席执行官 Satya Nadella 曾表示，AI 正在微软内部编写相当一部分代码，尤其是在新项目中，而 Python 是 AI 生成代码取得显著进展的语言之一 [2]。这引发了一种猜测：如果 AI 能够编写甚至优化代码，那么专门致力于语言性能优化的人类团队，其重要性是否会下降，或者成为可以削减的成本？ [2]。

然而，Python 本身就是 AI/ML 生态系统的基石。提升 Python 的核心性能，理应有助于微软的 AI 战略。这构成了一个看似矛盾的局面。微软对 AI 的巨大投入，与削减一个旨在加速 Python（AI领域的主导语言）的团队，两者之间存在明显的张力。Python 的速度直接影响许多 AI 工作负载的效率，包括模型训练、数据处理和推理。这种矛盾或许暗示，微软可能认为其自有的 AI 工具和基础设施（如 Azure ML、特定库）足以满足其对 Python 性能的需求，使得通用 CPython 的速度对其自身业务的直接优先级有所下降；或者，从该特定团队削减的成本被认为优先于对更广泛 AI 生态系统（微软亦是其中一员）的间接但可能显著的益处；甚至，存在一种更具推测性的解读，即微软预期 AI 本身将在不久的将来处理此类语言层面的优化工作。

经济压力与股东价值：利润增长下的“降本增效”

尽管微软公布了强劲的季度利润（例如 Q3 净收入高达 258 亿美元）5，但大型科技公司在后疫情时代招聘潮之后，纷纷通过裁员来“精简团队”和“调整战略” [5]。一些社区成员认为，这类裁员更多的是向投资者展示财务纪律的“善意姿态”，而非完全基于运营必要性或特定团队的绩效 [13]。

这种决策可能优先考虑了即时的成本削减和对投资者的积极信号，而牺牲了更快核心 Python 所带来的长期战略价值以及通过支持此类基础开源项目所积累的社区好感。尽管公司盈利丰厚 [5]，但此举符合科技行业通过裁员来显示财务审慎的普遍趋势。对于季度财报而言，Faster CPython 团队的贡献可能难以直接量化为其主要产品收入的增长，而一个更高效的 Python 生态系统、因良好 Python 支持而吸引开发者使用微软平台等长期利益，则更难衡量且不具即时性。

“够用就好”论与“远离利润中心”的风险

在 Hacker News、Reddit 等技术社区的讨论中，一个反复出现的主题是：Faster CPython 团队的工作虽然技术上卓越，但可能未被微软高层视为能直接转化为“清晰、可衡量的商业成果” [13]。观点认为，管理层可能觉得 CPython 现有的性能已经“够用”，进一步的核心优化对于微软的核心收入流而言，并不能带来实质性的提升 [13]。那些被视为“成本中心”或与直接产生利润和亏损（P&L）的业务距离较远的团队，在裁员时往往更加脆弱 [13]。

如果作为 AI 领域重要参与者的微软认为，在已达成的基础上进一步提升核心CPython 速度对其自身的商业目标并非至关重要，这可能暗示其主要的性能瓶颈被认为存在于别处（例如数据 I/O、GPU 利用率、分布式计算），或者通过其他手段得到解决。这并不意味着 CPython 不能更快，或者其他用户不会从中受益，但这反映了特定企业对其投资回报率的计算。此举可能无意中传递出一家主要企业赞助商对核心 Python 性能雄心降低的信号，除非其他赞助商以类似资源介入，否则可能影响对更激进核心优化的推动力。这反映了大型企业在资助基础/研发工作与优先考虑具有即时、可量化回报的项目之间普遍存在的张力。

速度的遗产：Faster CPython 团队的深远影响

项目的缘起：一项雄心勃勃的 Python 提速计划

Faster CPython 项目的蓝图最初由 Mark Shannon 于 2020 年 10 月勾勒，目标是在四年内将 CPython 的速度提升五倍（约每年提升 50%），但这一计划的实现有赖于资金支持 [8]。Python 的创造者 Guido van Rossum 在结束短暂的退休生涯并加入微软后，选择致力于这一方向，并促成了微软对一个小规模团队的资助 [7]。这个最初由 Guido van Rossum、Mark Shannon 和 Eric Snow 组成，后续可能扩充的团队 [8]，最终发展到约 6 名工程师 [7]。微软将此举定位为“微软回馈 Python 社区的方式” [16]。这个项目从一开始就拥有清晰、宏大且公开的目标，并得到了 Python 世界重量级人物的鼎力支持。

核心成就与贡献斐然

Faster CPython 团队在相对较短的时间内取得了显著成就，充分证明了专注的、有资金支持的专业团队对基础开源项目的巨大推动作用。这不仅加速了超越纯志愿者努力所能达到的进展，也为企业赞助加速关键开源基础设施发展提供了有力例证。

  • Python 3.11：性能的重大飞跃：该版本被广泛认为是团队工作的直接成果，相较于 Python 3.10 实现了 10% 到 60% 的速度提升 [3]。
  • PEP 659：特化自适应解释器 (Specializing Adaptive Interpreter)：这是 Python 3.11 性能提升的基石 [8]。由 Mark Shannon 撰写的 PEP 659 [19]，其核心思想是让解释器在运行时根据遇到的类型和值进行自适应调整，用特化的字节码指令替换通用的字节码指令。简而言之，解释器会观察运行时的实际数据模式，并将通用指令（如二进制加法）替换为更快的、针对特定类型的指令（如整数加法），同时保留一个回退机制，以防最初的假设不再成立 [18]。
  • 解散前的持续工作：根据最初的计划，针对 Python 3.12 和 3.13 的工作包括进一步的“微调”、改进整数性能、加速函数调用和返回、优化对象内存布局、实现零开销异常处理，并最终引入 JIT (Just-In-Time) 编译器 [15]。针对 3.13/3.14 版本的 JIT 编译器工作也已在进行中 [20]。此外，由 Eric Snow 主导的“自由线程”（Per-Interpreter GIL, PEP 684）[22] 是另一个旨在改善 Python 并行处理能力的重要领域。 这些努力并非孤立存在，而是构成了一个相互关联的项目组合，例如特化解释器、JIT 编译、自由线程和垃圾回收（GC）改进等 [15]。一个领域的成功往往为其他领域奠定基础或依赖于其他领域的进展。团队的解散打乱了这些协同工作的节奏，因为这些举措是一个整体战略的组成部分，团队内部很可能存在知识共享和相互依赖。

团队成员及其专注领域

下表列出了 Faster CPython 项目（在微软支持下）的一些关键里程碑及其主要贡献者：

Python 版本目标关键举措/PEP主要目标/描述已实现/报告的收益 (如适用)主要贡献者 (部分列举)
3.10自适应、特化解释器 (初步工作)解释器根据类型和值进行自适应，利用类型稳定性，无需运行时代码生成 [15]为 3.11 的重大改进奠定基础Mark Shannon, Guido van Rossum
3.11PEP 659: 特化自适应解释器运行时用特化字节码替换通用字节码，显著提升性能 [18]10-60% 速度提升 [9]Mark Shannon, Guido van Rossum, Brandt Bucher
3.11异常组 (Exception Groups) 和 except*改进错误处理机制 [23]Python 3.11 新特性Irit Katriel, Guido van Rossum
3.12 (计划)运行时和关键对象的改进，"微调"改进小整数性能、二元操作符、调用返回、对象内存布局、零开销异常处理 [15]计划中整个团队
3.12/3.13 (计划)PEP 684: Per-Interpreter GIL (自由线程)允许多个子解释器并行运行，每个解释器拥有自己的 GIL，以改善多核利用率 [22]计划中，部分基础工作已完成Eric Snow
3.13 (计划)简单的 JIT 编译器 (针对小区域)为小的特化代码区域编译生成机器码 [15]实验性 JIT 已在 3.13 中引入 21Brandt Bucher, Mark Shannon
3.14+ (计划)扩展编译区域，增强编译器，改进 GC，虚拟引用计数生成更优机器码，提升垃圾回收效率，减少引用计数开销 [15]计划中Mark Shannon (GC/ref counting), 整个团队 (JIT)
整体目标CPython 速度提升 5 倍分四个阶段，每个阶段提升约 50% [15]Python 3.11 已取得显著进展Mark Shannon (初始计划), 整个 Faster CPython 团队

团队在 Python 3.11 上取得的成功，从根本上改变了关于 CPython 性能的讨论格局，证明了在不破坏兼容性的前提下实现显著性能提升是可能的 [8]。这为未来的 CPython 版本以及其他 Python 实现设立了更高的标杆，也培养了社区对持续性能改进的期待。如今团队的解散，无疑给通过同一 CPython 开发渠道满足这些更高期望蒙上了一层阴影。

社区的震动与忧虑之声

失望与不解情绪蔓延

微软解散 Faster CPython 团队的消息在 Python 社区引发了轩然大波。在 Reddit 的 r/Python、r/programming 子版块以及 Hacker News 等技术论坛上，弥漫着失望和不解的情绪。许多用户称此举为“糟糕的决定”，并对由此造成的损失表示惋 meninas [1]。考虑到 Python 语言的重要性，不少人质疑这一决策的短视性 [3]。团队成员在前往 PyCon 途中获悉被裁的消息，这一细节尤其令人感到遗憾 [2]。部分开发者甚至表达了对企业赞助模式乃至微软本身的信任危机 [25]。

来自受影响成员和 Python 领袖的声音

  • Mike Droettboom (团队负责人) 公开表示：“过去的几天非常艰难。微软对 Faster CPython 项目的支持于昨日取消，我为团队中大多数被解雇的成员感到心痛。” [1]。他还提到，团队原计划在 PyCon 的 Python 语言峰会上讨论相关工作进展 [2]。
  • Brett Cannon (CPython 核心开发者) 率先披露了 Mark Shannon、Eric Snow 和 Irit Katriel 被解雇的消息，并呼吁社区为他们提供工作机会线索 [3]。
  • Guido van Rossum (Python 创始人)：尽管在 2025 年 5 月的事件中，现有资料未包含他对此事的直接公开声明，但他早期对团队重要性的肯定 [7] 为理解此次变故的严重性提供了背景。他作为团队一员，为项目赋予了巨大的公信力。

激辩：专业知识的价值 vs. 商业现实的残酷

社区讨论中一个反复出现的主题是：如果深厚的技术专长不能直接转化为立竿见影、可衡量的商业成果，其价值似乎就会被低估 13。一些人认为，被解雇的开发者才华横溢，但他们的角色“未能为雇佣他们的企业带来足够的现实世界价值” [13]。另一些人则反驳说，这是“糟糕的领导层专注于短期利益”的结果，在微软这样体量的公司，人事决策有时可能与实际利润或团队价值脱钩 [13]。

尽管微软曾公开承诺并赞扬 Faster CPython 团队 [7]，但这种突然撤销支持的行为，尤其是在没有清晰、体恤社区的过渡计划的情况下 [1]，可能会侵蚀开源社区与企业赞助商之间的信任。这可能导致社区在未来的合作中更加谨慎，或避免过度依赖单一的捐助者，正如一些评论所言“永远不要相信微软” [25]。

社区的讨论还凸显了在大型企业中从事基础技术或研发工作的工程师普遍存在的一种焦虑：他们所从事的工作即便具有战略重要性或技术卓越性，但由于与直接创收活动的距离较远，使其在裁员面前显得尤为脆弱 [13]。这可能对顶尖人才在企业内部追求此类职位的积极性产生负面影响。

此外，如此高调地裁撤一个在备受喜爱的开源语言上做出贡献且备受尊敬的团队，可能会对微软在 Python 开发者心目中的形象造成负面影响，进而可能波及人才吸引以及开发者对其 Python 相关工具和平台的采用意愿。微软在开源社区和开发者中投入了大量资源以改善自身形象，而此举可能被视为一种倒退。

CPython 性能的未来：前路何在？

社区主导的倡议浮出水面

面对微软的突然退出，Python 社区迅速展现出其韧性。有提案建议成立一个“性能工作组 (performance-wg)”，以取代之前微软和 Meta 参与的 Faster CPython 同步会议 [20]。长期参与 Faster CPython 项目的社区志愿者 Ken Jin 是这一倡议的积极推动者。社区管理模式被提议效仿 Python 的 Typing Council (PEP 729) [20]。一个关键的转变是，在缺乏企业赞助的情况下，未来 JIT 编译器的开发将优先考虑可维护性而非极致性能 [20]。

Ken Jin 提出的在缺乏企业赞助的情况下优先考虑 JIT 可维护性而非极致性能的观点 20，是一种务实的调整。企业资助使得团队有资源追求像速度提升 5 倍和复杂 JIT 这样的宏大目标 [15]。相比之下，社区主导的项目通常依赖志愿者的时间，更强调由更广泛贡献者群体实现的长期可维护性。因此，从追求原始性能转向优先保障可维护性，是应对失去专门企业支持的理性适应，这可能意味着某些高级功能的开发步伐会放缓，或者会倾向于选择复杂度较低的解决方案。

利用现有基础设施与知识积累

幸运的是，Faster CPython 团队的工作成果并非完全付诸东流。Python 软件基金会 (PSF) 拥有的基准测试基础设施，包括由 ARM 捐赠的基准测试机器以及开源的 bench_runner 工具 [20]，为后续工作提供了基础。更重要的是，微软团队所做的大部分工作都是开源的，并且已经贡献给了上游 CPython 项目 [8]，这意味着社区可以在此基础上继续构建。

这种开放性确保了即使在企业赞助结束后，其投入所产生的知识、代码（如 PEP 659 已成为 CPython 的一部分 [19]）和工具（如 bench_runner 20）仍然可供 Python 项目使用。这与那些一旦取消就可能导致所有工作成果消失的专有项目形成鲜明对比，彰显了开源模式的“红利效应”。

持续的技术探索与未来方向（社区视角）

从技术层面看，CPython 的性能优化之路并未中断：

  • JIT 编译器：设计思路将转向更注重可维护性 [20]。此前，提升 JIT 速度和生成更优代码的工作已在进行中 [21]。
  • 自由线程 (Free-threading)：相关工作仍在继续，Meta 的 Python 运行时团队也在为提升自由线程构建下的单线程性能做出贡献 21。
  • 解释器与垃圾回收 (GC) 增强：这些领域依然在社区的关注范围内 [21]。
  • 在被解雇前，Mark Shannon 一直在研究虚拟/嵌入式引用计数以及调整增量式 GC [21]。这些具体工作的后续进展尚不明朗。

其他企业角色的潜在作用

CPython 的性能提升并非完全依赖于单一实体，其他企业和项目的角色可能会更加突出：

  • Meta (Facebook)：拥有其 Cinder 项目和一个致力于性能（包括自由线程）的 Python 运行时团队 [18]。他们曾与 CPython 团队有过合作 18，并可能承办未来的性能工作组同步会议 [20]。
  • Nvidia：部分社区成员猜测 Nvidia 可能会介入，因为其平台对 PyTorch 等 Python 库有高度依赖 25。但也有观点指出，PyTorch 主要基于 C++/CUDA，从 CPython 核心速度提升中获得的直接益处可能不如从无 GIL 的 Python 中获得的多 [25]。
  • Pyston, PyPy：这些是专注于性能的替代 Python 实现 [[26] (Pyston 详情), [21] (提及 PyPy 更快)]。CPython 当前的局面可能会促使更多开发者关注或贡献这些项目。

随着微软在核心 CPython 性能方面直接投入的减少，Meta、Anaconda（Pyston 的赞助商 [26]）等其他参与者在 Python 性能领域的作用变得更加关键。这可能催生一个更丰富的 高性能 Python 选项生态系统，但如果缺乏像拟议中的性能工作组这样的协调机制，也可能导致性能解决方案的碎片化。

反思：Faster CPython 事件带来的启示

企业赞助开源的双刃剑效应

Faster CPython 项目的经历生动地展示了企业赞助对开源项目的双重影响。一方面，它能带来显著的好处：加速开发进程、提供专用资源、使得攻克宏大目标成为可能（正如 Faster CPython 团队所取得的成就）。另一方面，它也带来了风险：项目容易受到企业战略转变、预算削减或优先事项变更的冲击，甚至可能过度依赖单一捐助者。尽管此次事件的意图或许并非如此，但历史上对“拥抱、扩展、消灭”(Embrace, Extend, Extinguish) 的担忧 [17]，反映了社区对企业参与开源的一种历史性怀疑。

这一事件凸显了关键开源基础设施过度依赖单一企业赞助商的系统性风险。它可能会推动关于为 CPython 等核心项目建立更多元化资金模型（例如，企业联盟、更强大的基金会支持、多个企业赞助商）和更强健的社区主导治理机制的讨论和行动，以确保其长期可持续性和韧性。

社区协作的持久力量

面对挫折，Python 社区迅速响应，开始组织和规划后续管理工作 20，这充分体现了开源模式的韧性。与其他力量（如 Meta [20]）的协作价值也因此变得更加重要。

微软对 Python 承诺的演变（或退化？）

微软曾将自己定位为 Python 的坚定支持者，进行了大量投资（如 VS Code、Azure、Python in Excel [27]，以及 Faster CPython 团队本身 [7]）。此次行动引发了人们对其承诺深度和长期性的质疑，特别是针对语言基础层面与特定产品集成之间的平衡 [2]。一篇微软官方博文曾宣传其对 Python 的承诺，如今被社区成员评价为“像牛奶一样迅速变质” [25]，这尖锐地反映了当前的疑问：微软是否会继续以其他方式资助核心 Python 开发，或者这标志着其从此类深度参与中战略性后撤？

微软曾将 Faster CPython 团队定位为“回馈 Python 社区” [16]。其项目的突然终止，可能会促使开源社区在未来更仔细地审视这类“善举”，寻求更可持续、目标更一致的承诺，而非那些在企业优先事项转变时轻易就能被削减的项目。这可能导致未来企业与社区的合作中出现更正式的协议或期望。

“基础技术”岗位在大型科技公司的前景

此次裁员以及社区的相关讨论 [13]，为在大型企业中从事基础性、长期研发或基础设施项目的工程师敲响了警钟：与直接营收的距离感可能成为一种职业风险。这一事件可能会影响开发者未来的职业路径选择，以及他们如何在企业架构内倡导基础工作的价值。

然而，从另一个角度看，尽管微软专项团队的解散是一个挫折，但也可能无心插柳地激励更广泛的社区成员和小型组织加大对 CPython 性能优化的贡献力度。这或许会催生一种更为分散但可能同样富有活力的创新模式，由众多贡献者共同推动 Python 性能的持续进步。

结语

微软解散 Faster CPython 团队的决定，无疑是 Python 发展历程中的一个重要转折点。其背后原因复杂，既有企业整体战略调整的宏观因素，也可能掺杂着对项目投入产出比的短期考量，以及对 AI 技术发展趋势的判断。无论原因为何，这一决策对 Python 社区，特别是对那些为 CPython 性能提升付出心血的开发者们，都带来了不小的冲击。

然而，回顾整个事件，我们既看到了企业赞助模式的脆弱性，也目睹了开源社区强大的生命力和自我修复能力。Faster CPython 团队在微软支持下取得的成就是不可磨灭的，他们不仅实实在在地提升了 Python 的运行速度，更为后续的性能优化工作奠定了坚实的基础。这些以开源形式贡献出来的知识和代码，将成为社区继续前行的宝贵财富。

前路或许会与最初的设想有所不同，可能会更加依赖多元化的社区力量和不同企业间的协作，而非单一巨头的强力推动。但追求更快、更强 Python 的脚步，大概率不会因此停歇。这起事件也再次将一个经典问题摆在世人面前：在商业利益与开源精神之间，大型科技企业应如何扮演其角色，才能实现真正可持续的共赢？这值得整个行业深思。

引用的著作

  1. Microsoft support for "Faster CPython" project cancelled : r/programming - Reddit, https://www.reddit.com/r/programming/comments/1kncoi8/microsoft_support_for_faster_cpython_project/
  2. Microsoft winnows: Layoffs hit software engineers hard - The Register, https://www.theregister.com/2025/05/16/microsofts_axe_software_developers/
  3. Microsoft layoffs hit Faster CPython team - including the Technical Lead, Mark Shannon : r/Python - Reddit, https://www.reddit.com/r/Python/comments/1kmwdbu/microsoft_layoffs_hit_faster_cpython_team/
  4. Brett Cannon: "There were layoffs at MS yeste…" - Fosstodon, https://fosstodon.org/@brettcannon/114508255258349907
  5. Microsoft lays off about 3% of its workforce in what one executive calls a 'day with a lot of tears' - Action News Jax, https://www.actionnewsjax.com/news/microsoft-lays-off/OPINBIDWPNHQ5IHM2KDKFFIS2I/
  6. Microsoft Layoffs: Software Engineers, Product Managers Cut | Entrepreneur, https://www.entrepreneur.com/business-news/microsoft-layoffs-software-engineers-product-managers-cut/491704
  7. A Team at Microsoft is Helping Make Python Faster, https://devblogs.microsoft.com/python/python-311-faster-cpython-team/
  8. The 2021 Python Language ... - Python Software Foundation News, https://pyfound.blogspot.com/2021/05/the-2021-python-language-summit-making.html
  9. Keynote - Open Source Contributors in Space and Time :: SciPy 2023 :: pretalx, https://cfp.scipy.org/2023/talk/X7YH7A/
  10. Microsoft Assisting in Making Python Faster - devmio, https://devm.io/python/microsoft-team-python
  11. Blog - Microsoft Layoffs - Michael Tsai, https://mjtsai.com/blog/2025/05/15/microsoft-layoffs/
  12. 'Developers will need to adapt': Microsoft CEO Satya Nadella joins Google's Sundar Pichai in revealing the scale of AI-generated code at the tech giants – and it's a stark warning for software developers - ITPro, https://www.itpro.com/software/development/developers-will-need-to-adapt-microsoft-ceo-satya-nadella-joins-googles-sundar-pichai-in-revealing-the-scale-of-ai-generated-code-at-the-tech-giants-and-its-a-stark-warning-for-software-developers
  13. What CPython Layoffs Taught Me About the Real Value of Expertise : r/Python - Reddit, https://www.reddit.com/r/Python/comments/1kok2e1/what_cpython_layoffs_taught_me_about_the_real/
  14. Tell HN: What CPython Layoffs Taught Me About the Real Value of ..., https://news.ycombinator.com/item?id=44011952
  15. faster-cpython/plan.md at master - GitHub, https://github.com/markshannon/faster-cpython/blob/master/plan.md
  16. Guido van Rossum aiming to make CPython 2x faster in 3.11 - The Register, https://www.theregister.com/2021/05/13/guido_van_rossum_cpython_3_11/
  17. Microsoft Funds a Team with Guido van Rossum to Double the Speed of Python - Slashdot, https://developers.slashdot.org/story/21/05/17/0225252/microsoft-funds-a-team-with-guido-van-rossum-to-double-the-speed-of-python
  18. Episode #381 - Python Perf: Specializing, Adaptive Interpreter | Talk ..., https://talkpython.fm/episodes/show/381/python-perf-specializing-adaptive-interpreter
  19. PEP 659 – Specializing Adaptive Interpreter | peps.python.org, https://peps.python.org/pep-0659/
  20. Community Stewardship of Faster CPython - Core Development ..., https://discuss.python.org/t/community-stewardship-of-faster-cpython/92153
  21. Communication about faster-cpython after 3.13 release? · Issue ..., https://github.com/faster-cpython/ideas/issues/701
  22. Subinterpreters and Getting a PEP Accepted with Eric Snow | Microsoft Learn, https://learn.microsoft.com/en-us/shows/microsoft-at-pycon-us-2023/subinterpreters-and-getting-a-pep-accepted-with-eric-snow
  23. Irit Katriel - PyCon US 2024, https://us.pycon.org/2024/speaker/profile/4/index.html
  24. CPython Developer Panel - Łukasz Langa, Pablo Galindo Salgado, Mark Shannon, Steve Dower, Irit Katriel, Batuhan Taskaya, Ken Jin - EuroPython 2022, https://ep2022.europython.eu/session/cpython-developer-panel/
  25. Microsoft Fired Faster CPython Team : r/Python - Reddit, https://www.reddit.com/r/Python/comments/1koev5c/microsoft_fired_faster_cpython_team/
  26. pyston/pyston: (No longer maintained) A faster and highly-compatible implementation of the Python programming language. - GitHub, https://github.com/pyston/pyston
  27. microsoft/pycon - GitHub, https://github.com/microsoft/pycon