Microsoft Disbands Faster CPython Team:What's Next for Python Performance?

Microsoft announced the disbandment of the Faster CPython team, with this article generated by Google Gemini Deep Research.

---

Python, as one of the most popular programming languages today, has won the favor of developers worldwide with its concise syntax and vast ecosystem. However, performance issues, especially speed when compared to compiled languages like C/C++, have always been a focus for users and developers of CPython (the official and most widely used implementation of Python). On the long journey of improving Python performance, Microsoft once played a key driving role, and its sponsored Faster CPython team achieved remarkable results. However, a sudden piece of news shook the entire Python community: Microsoft decided to disband this core team dedicated to improving CPython performance. This decision not only surprised many but also sparked profound discussions about corporate sponsorship of open source projects, the value of technical experts, and the future direction of Python's performance. This article aims to evaluate Microsoft's move, explore its potential impact, and look forward to the future path of CPython performance optimization.

Abrupt Halt: Microsoft Disbands Its Acclaimed Faster CPython Team

Bolt from the Blue: Project Support Canceled, Team Members Dispersed

In May 2025, news quickly spread that Microsoft was canceling support for the Faster CPython project and laying off most of its team members [1]. Mike Droettboom, a Principal Software Engineering Manager at Microsoft and CPython core developer, confirmed the news on his social media, expressing deep sympathy and regret for the affected team members [1]. This change not only means that a highly anticipated performance improvement plan may come to an abrupt end but also that the Python community has lost a powerful force composed of top experts focused on core optimization.

According to news released by CPython core developer Brett Cannon, the layoffs affected several core members of the Faster CPython team, including the project's technical lead and initiator Mark Shannon, as well as senior core developers Eric Snow and Irit Katriel [3]. These names are well-known in the Python community, and their departure is undoubtedly a significant loss for the CPython performance optimization field. The Faster CPython team was a high-profile, publicly supported Microsoft initiative, and its sudden termination caught the community by surprise and caused confusion.

Timing and Context: A Ripple in Microsoft's Large-Scale Layoff Wave

This adjustment targeting the Faster CPython team was not an isolated event but part of Microsoft's global large-scale layoff plan. According to reports, Microsoft announced a global reduction of approximately 3% of its workforce, affecting nearly 7,000 positions [2]. In Washington state, where its headquarters are located, nearly 2,000 positions were cut, with software engineering roles being particularly hard hit, as 817 software engineer positions were reduced at the Redmond headquarters alone [2].

The layoffs affected multiple departments within Microsoft, including teams like TypeScript and Azure SDK [2], indicating a broad cost-cutting or strategic adjustment action. What is regrettable is that many team members received their layoff notices while traveling to Pittsburgh to attend PyCon (the Python developer conference) and its Language Summit [2]. This detail revealed by Mike Droettboom not only highlights the suddenness of the event but also, to some extent, reflects a possible lack of consideration for individual emotions and community impact at the execution level of corporate decisions.

This timing choice transformed a business decision into an impact with more personal and public sentiment. Behind this may lie a disconnect between high-level corporate decisions and grassroots execution and community impact, or perhaps merely strict adherence to a predetermined layoff schedule without fully considering such significant external activities.

Looking deeper, the disbandment of the team is not just the loss of a few individual contributors but the dismantling of a cohesive unit that had formed a collaborative knowledge system and a clear mission [7]. This team brought together outstanding talents such as Mark Shannon, Python creator Guido van Rossum, Eric Snow, and Irit Katriel [7], and their close collaboration and Microsoft's financial support led to significant performance improvements in versions like Python 3.11 [9]. Now, this highly focused professional force and R&D momentum have been forcibly interrupted, and even if these experts continue to contribute in a personal capacity in the future, it will be difficult to replicate such an organized and funded dedicated environment in a short period.

Exploring the Reasons: Interpreting Microsoft's Possible Motives for This Move

Microsoft's Official Statement: Vague and Standard

Regarding these layoffs, Microsoft's official explanation was, as usual, standard and vague: "We continue to make organizational changes to ensure the company is optimally positioned for success in a dynamic market" [2]. This statement provided almost no specific reason for the CPython team layoffs. Microsoft CFO Amy Hood mentioned in April the need to "increase agility by reducing management layers" [2], and the company also stated that one focus of these layoffs was reducing management personnel [5], but the reality is that a large number of software engineers were affected [2]. This type of general statement is common during corporate layoffs, often hiding more complex or specific reasons, thus triggering various external speculations.

Considerations Amidst the AI Wave: A Double-Edged Sword?

Microsoft is investing heavily in artificial intelligence and data center construction [2]. Company CEO Satya Nadella once stated that AI is writing a significant portion of code internally at Microsoft, especially in new projects, and Python is one of the languages where AI-generated code has made significant progress [2]. This has led to speculation: if AI can write or even optimize code, will the importance of human teams specifically dedicated to language performance optimization decrease, or will they become a cost that can be cut? [2].

However, Python itself is a cornerstone of the AI/ML ecosystem. Improving the core performance of Python should logically help Microsoft's AI strategy. This presents a seemingly contradictory situation. There is obvious tension between Microsoft's huge investment in AI and the reduction of a team aimed at accelerating Python, the dominant language in the AI field. Python's speed directly affects the efficiency of many AI workloads, including model training, data processing, and inference. This contradiction might suggest that Microsoft may believe its own AI tools and infrastructure (such as Azure ML, specific libraries) are sufficient to meet its Python performance needs, making the speed of general CPython less of a direct priority for its own business; or, that the cost savings from this specific team are deemed a higher priority than the indirect but potentially significant benefits to the broader AI ecosystem (of which Microsoft is also a part); or even, there is a more speculative interpretation that Microsoft expects AI itself to handle such language-level optimization work in the near future.

Economic Pressure and Shareholder Value: "Cost Reduction and Efficiency Increase" Amidst Profit Growth

Although Microsoft reported strong quarterly profits (e.g., Q3 net income as high as $25.8 billion) [5], large tech companies, after the post-pandemic hiring boom, have successively resorted to layoffs to "streamline teams" and "adjust strategies" [5]. Some community members believe that these layoffs are more of a "goodwill gesture" to show financial discipline to investors rather than being solely based on operational necessity or specific team performance [13].

This decision likely prioritized immediate cost savings and positive signals to investors, at the expense of the long-term strategic value brought by a faster core Python and the community goodwill accumulated by supporting such foundational open source projects. Although the company is highly profitable [5], this move aligns with the general trend in the tech industry to demonstrate financial prudence through layoffs. For quarterly financial reports, the contributions of the Faster CPython team might be difficult to directly quantify as growth in core product revenue, while the long-term benefits such as a more efficient Python ecosystem and attracting developers to use Microsoft platforms due to good Python support are harder to measure and not immediate.

The "Good Enough" Argument and the Risk of Being "Far from the Profit Center"

In discussions on technical communities like Hacker News and Reddit, a recurring theme is that while the work of the Faster CPython team was technically excellent, it might not have been perceived by Microsoft management as directly translating into "clear, measurable business outcomes" [13]. The view is that management might have felt that CPython's existing performance was "good enough," and further core optimizations would not bring substantial improvements to Microsoft's core revenue streams [13]. Teams considered "cost centers" or those far removed from businesses that directly generate profit and loss (P&L) are often more vulnerable during layoffs [13].

If Microsoft, as a significant player in the AI field, believes that further improving the core CPython speed beyond what has been achieved is not crucial for its own business objectives, this might suggest that its main performance bottlenecks are considered to be elsewhere (e.g., data I/O, GPU utilization, distributed computing), or are addressed through other means. This does not mean that CPython cannot be faster, or that other users would not benefit, but it reflects a specific company's calculation of its return on investment. This move might inadvertently signal a major corporate sponsor's diminished ambition for core Python performance, and unless other sponsors step in with similar resources, it could affect the momentum for more aggressive core optimizations. This reflects the common tension within large corporations between funding foundational/R&D work and prioritizing projects with immediate, quantifiable returns.

The Legacy of Speed: The Far-Reaching Impact of the Faster CPython Team

The Project's Origin: An Ambitious Python Acceleration Plan

The blueprint for the Faster CPython project was initially outlined by Mark Shannon in October 2020, with the goal of increasing CPython's speed fivefold within four years (roughly 50% improvement annually), but the realization of this plan was contingent on funding support [8]. Python's creator Guido van Rossum, after a brief retirement and joining Microsoft, chose to dedicate himself to this direction and facilitated Microsoft's sponsorship of a small team [7]. This team, initially consisting of Guido van Rossum, Mark Shannon, and Eric Snow, and potentially expanding later [8], eventually grew to about 6 engineers [7]. Microsoft positioned this move as "Microsoft giving back to the Python community" [16]. From the outset, this project had clear, ambitious, and public goals, and received strong support from heavyweights in the Python world.

Core Achievements and Significant Contributions

The Faster CPython team achieved remarkable results in a relatively short period, fully demonstrating the tremendous impetus that focused, well-funded professional teams can provide to foundational open source projects. This not only accelerated progress beyond what purely volunteer efforts could achieve but also provided a powerful example of corporate sponsorship accelerating the development of critical open source infrastructure.

• Python 3.11: A Major Performance Leap: This version is widely regarded as a direct result of the team's work, achieving a speed increase of 10% to 60% compared to Python 3.10 [3].
• PEP 659: Specializing Adaptive Interpreter: This is the cornerstone of Python 3.11's performance improvements [8]. PEP 659 [19], authored by Mark Shannon, has the core idea of allowing the interpreter to adaptively adjust at runtime based on the types and values encountered, replacing general bytecode instructions with specialized ones. In short, the interpreter observes actual data patterns at runtime and replaces generic instructions (like binary addition) with faster, type-specific instructions (like integer addition), while retaining a fallback mechanism in case the initial assumptions no longer hold [18].
• Ongoing Work Before Disbandment: According to the original plan, work for Python 3.12 and 3.13 included further "tuning," improving integer performance, accelerating function calls and returns, optimizing object memory layout, implementing zero-overhead exception handling, and eventually introducing a JIT (Just-In-Time) compiler [15]. Work on the JIT compiler for versions 3.13/3.14 was also underway [20]. Furthermore, "free-threading" (Per-Interpreter GIL, PEP 684) [22], led by Eric Snow, was another important area aimed at improving Python's parallel processing capabilities. These efforts were not isolated but formed a portfolio of interconnected projects, such as the specializing interpreter, JIT compilation, free-threading, and garbage collection (GC) improvements [15]. Success in one area often laid the foundation for or depended on progress in other areas. The team's disbandment disrupted the rhythm of this collaborative work, as these initiatives were part of a holistic strategy, and knowledge sharing and interdependencies likely existed within the team.

Team Members and Their Areas of Focus

The table below lists some key milestones of the Faster CPython project (under Microsoft's sponsorship) and their main contributors:

Python Version Target	Key Initiative/PEP	Main Goal/Description	Achieved/Reported Gains (if applicable)	Main Contributors (partial list)
3.10	Adaptive, Specializing Interpreter (initial work)	Interpreter adapts based on types and values, leveraging type stability, no runtime code generation needed [15]	Laid the groundwork for 3.11's major improvements	Mark Shannon, Guido van Rossum
3.11	PEP 659: Specializing Adaptive Interpreter	Runtime replacement of generic bytecode with specialized bytecode, significant performance boost [18]	10-60% speed increase [9]	Mark Shannon, Guido van Rossum, Brandt Bucher
3.11	Exception Groups and except*	Improved error handling mechanisms [23]	New feature in Python 3.11	Irit Katriel, Guido van Rossum
3.12 (Planned)	Runtime and key object improvements, "tuning"	Improved small integer performance, binary operators, call/return, object memory layout, zero-overhead exception handling [15]	Planned	The whole team
3.12/3.13 (Planned)	PEP 684: Per-Interpreter GIL (Free-threading)	Allows multiple sub-interpreters to run in parallel, each with its own GIL, to improve multi-core utilization [22]	Planned, some foundational work done	Eric Snow
3.13 (Planned)	Simple JIT Compiler (for small regions)	Compile machine code for small specialized code regions [15]	Experimental JIT introduced in 3.13 [21]	Brandt Bucher, Mark Shannon
3.14+ (Planned)	Expand compilation regions, enhance compiler, improve GC, virtual ref counting	Generate better machine code, improve garbage collection efficiency, reduce reference count overhead [15]	Planned	Mark Shannon (GC/ref counting), The whole team (JIT)
Overall Goal	5x CPython speed increase	Four phases, each increasing speed by about 50% [15]	Significant progress made in Python 3.11	Mark Shannon (initial plan), The entire Faster CPython team

The team's success with Python 3.11 fundamentally changed the landscape of discussion around CPython performance, proving that significant performance improvements are possible without breaking compatibility [8]. This set a higher benchmark for future CPython versions and other Python implementations, and also cultivated community expectations for continuous performance improvements. Now, the disbandment of the team undoubtedly casts a shadow over meeting these higher expectations through the same CPython development channel.

Community Shock and Voices of Concern

Disappointment and Confusion Spread

The news of Microsoft disbanding the Faster CPython team caused an uproar in the Python community. On technical forums such as Reddit's r/Python, r/programming subreddits, and Hacker News, feelings of disappointment and confusion were widespread. Many users called the move a "terrible decision" and expressed regret for the resulting loss [1]. Considering the importance of the Python language, many questioned the short-sightedness of this decision [3]. The detail that team members learned of the layoffs while traveling to PyCon was particularly regrettable [2]. Some developers even expressed a crisis of trust in the corporate sponsorship model and even Microsoft itself [25].

Voices from Affected Members and Python Leaders

• Mike Droettboom (Team Lead) publicly stated: "These last few days have been really rough. Yesterday, Microsoft ended support for the Faster CPython project, and I am heartbroken for most of the team members who were laid off." [1]. He also mentioned that the team was originally scheduled to discuss their progress at the Python Language Summit at PyCon [2].
• Brett Cannon (CPython core developer) was among the first to reveal the layoffs of Mark Shannon, Eric Snow, and Irit Katriel, and called on the community to provide job leads for them [3].
• Guido van Rossum (Python Creator): Although existing information did not include his direct public statement on this specific event in May 2025, his earlier affirmation of the team's importance [7] provides context for understanding the seriousness of this change. As a member of the team, he lent significant credibility to the project.

Heated Debate: The Value of Expertise vs. The Cruelty of Business Reality

A recurring theme in community discussions is that if deep technical expertise cannot be directly translated into immediate, measurable business outcomes, its value seems to be underestimated [13]. Some argue that the laid-off developers are talented, but their roles "failed to provide enough real-world value to the companies that employed them" [13]. Others countered that this is the result of "poor leadership focusing on short-term gains," and that in a company the size of Microsoft, personnel decisions can sometimes be disconnected from actual profits or team value [13].

Although Microsoft had publicly committed to and praised the Faster CPython team [7], this sudden withdrawal of support, especially without a clear, community-sensitive transition plan [1], could erode trust between the open source community and corporate sponsors. This might lead the community to be more cautious in future collaborations or avoid over-reliance on a single donor, as some comments suggested, "never trust Microsoft" [25].

Community discussions also highlighted a common anxiety among engineers working on foundational technology or R&D in large corporations: even if their work is strategically important or technically excellent, its distance from direct revenue-generating activities makes it particularly vulnerable during layoffs [13]. This could negatively impact the motivation of top talent to pursue such positions within corporations.

Furthermore, such a high-profile layoff of a respected team contributing to a widely loved open source language could negatively impact Microsoft's image among Python developers, potentially affecting talent attraction and developers' willingness to adopt its Python-related tools and platforms. Microsoft has invested significant resources in the open source community and among developers to improve its image, and this move might be perceived as a step backward.

The Future of CPython Performance: What Lies Ahead?

Community-Led Initiatives Emerge

Facing Microsoft's sudden withdrawal, the Python community quickly demonstrated its resilience. There is a proposal to establish a "performance working group (performance-wg)" to replace the Faster CPython sync-ups previously involving Microsoft and Meta [20]. Ken Jin, a long-time community volunteer contributing to the Faster CPython project, is a strong advocate for this initiative. A community-led management model is proposed, similar to Python's Typing Council (PEP 729) [20]. A key shift is that, without corporate sponsorship, future development of the JIT compiler will prioritize maintainability over peak performance [20].

Ken Jin's point [20] about prioritizing JIT maintainability over peak performance in the absence of corporate sponsorship is a pragmatic adjustment. Corporate funding allowed the team resources to pursue ambitious goals like a 5x speedup and a complex JIT [15]. In contrast, community-led projects typically rely on volunteer time and place greater emphasis on long-term maintainability achievable by a broader base of contributors. Therefore, shifting from pursuing raw performance to prioritizing maintainability is a rational adaptation to losing dedicated corporate support, which might mean a slower pace for developing certain advanced features or a preference for less complex solutions.

Leveraging Existing Infrastructure and Accumulated Knowledge

Fortunately, the work of the Faster CPython team is not entirely lost. The Python Software Foundation (PSF) has benchmark infrastructure, including benchmark machines donated by ARM and the open source bench_runner tool [20], which provides a foundation for future work. More importantly, most of the work done by the Microsoft team was open source and has already been contributed to the upstream CPython project [8], meaning the community can continue to build upon this basis.

This openness ensures that even after corporate sponsorship ends, the knowledge, code (such as PEP 659, which is now part of CPython [19]), and tools (such as bench_runner [20]) resulting from their investment remain available to the Python project. This stands in stark contrast to proprietary projects where all work results might disappear upon cancellation, highlighting the "dividend effect" of the open source model.

Continued Technical Exploration and Future Directions (Community Perspective)

From a technical perspective, the path of CPython performance optimization has not been interrupted:

• JIT Compiler: The design approach will shift towards prioritizing maintainability [20]. Previously, work to improve JIT speed and generate better code was underway [21].
• Free-threading: Related work is still ongoing, and Meta's Python runtime team is also contributing to improving single-thread performance under free-threading builds [21].
• Interpreter and Garbage Collection (GC) Enhancements: These areas remain within the community's focus [21].
• Before being laid off, Mark Shannon was researching virtual/embedded reference counting and tuning incremental GC [21]. The future progress of these specific efforts is unclear.

Potential Roles of Other Corporations

CPython's performance improvement is not solely dependent on a single entity; the roles of other companies and projects may become more prominent:

• Meta (Facebook): Has its Cinder project and a Python runtime team dedicated to performance, including free-threading [18]. They have collaborated with the CPython team [18] and might host future performance working group sync-ups [20].
• Nvidia: Some community members speculate that Nvidia might get involved due to its platform's high reliance on Python libraries like PyTorch [25]. However, some also point out that PyTorch is primarily based on C++/CUDA, and the direct benefits gained from CPython core speed improvements might be less significant than from a GIL-free Python [25].
• Pyston, PyPy: These are alternative Python implementations focused on performance [[26] (Pyston details), [21] (mentions PyPy is faster)]. The current situation for CPython might encourage more developers to focus on or contribute to these projects.

As Microsoft's direct investment in core CPython performance decreases, the roles of other participants like Meta, Anaconda (sponsor of Pyston [26]), and others in the Python performance field become more crucial. This could foster a richer ecosystem of high-performance Python options, but without a coordinating mechanism like the proposed performance working group, it could also lead to fragmentation of performance solutions.

Reflection: Lessons from the Faster CPython Incident

The Double-Edged Sword Effect of Corporate Sponsorship in Open Source

The experience of the Faster CPython project vividly illustrates the dual impact of corporate sponsorship on open source projects. On one hand, it can bring significant benefits: accelerating the development process, providing dedicated resources, and making it possible to tackle ambitious goals (as achieved by the Faster CPython team). On the other hand, it also brings risks: projects are vulnerable to shifts in corporate strategy, budget cuts, or changes in priorities, and may even become overly dependent on a single donor. While the intention of this event may not have been such, the historical concerns about "Embrace, Extend, Extinguish" [17] reflect a historical skepticism within the community towards corporate involvement in open source.

This incident highlights the systemic risk of critical open source infrastructure becoming overly reliant on a single corporate sponsor. It may drive discussions and actions towards establishing more diverse funding models (e.g., corporate consortia, stronger foundation support, multiple corporate sponsors) and more robust community-led governance mechanisms for core projects like CPython, to ensure their long-term sustainability and resilience.

The Enduring Power of Community Collaboration

Faced with setbacks, the Python community responded quickly, beginning to organize and plan for future stewardship [20], fully demonstrating the resilience of the open source model. The value of collaboration with other entities (such as Meta [20]) has consequently become even more crucial.

The Evolution (or Degeneration?) of Microsoft's Commitment to Python

Microsoft had positioned itself as a strong supporter of Python, making significant investments (such as VS Code, Azure, Python in Excel [27], and the Faster CPython team itself [7]). This action has raised questions about the depth and long-term nature of its commitment, particularly concerning the balance between foundational language work and specific product integration [2]. A Microsoft official blog post once promoted its commitment to Python, which community members now assess as having "soured quickly like milk" [25], sharply reflecting the current question: Will Microsoft continue to fund core Python development in other ways, or does this signal a strategic retreat from such deep involvement?

Microsoft had positioned the Faster CPython team as "giving back to the Python community" [16]. The sudden termination of the project might prompt the open source community to more carefully scrutinize such "good deeds" in the future, seeking more sustainable, goal-aligned commitments rather than projects that can be easily cut when corporate priorities shift. This could lead to more formal agreements or expectations in future collaborations between corporations and the community.

Prospects for "Foundational Technology" Roles in Large Tech Companies

These layoffs and the related community discussions [13] serve as a wake-up call for engineers working on foundational, long-term R&D, or infrastructure projects in large corporations: the distance from direct revenue generation can become a career risk. This event may influence developers' future career path choices and how they advocate for the value of foundational work within corporate structures.

However, from another perspective, although the disbandment of Microsoft's specialized team is a setback, it may inadvertently inspire broader community members and smaller organizations to increase their contributions to CPython performance optimization. This might foster a more decentralized but potentially equally dynamic model of innovation, with numerous contributors collectively pushing for continuous improvements in Python's performance.

Conclusion

Microsoft's decision to disband the Faster CPython team is undoubtedly a significant turning point in Python's development history. The reasons behind it are complex, including macro factors like overall corporate strategic adjustments, possibly mixed with short-term considerations of project input-output ratio, and judgments about the development trends of AI technology. Whatever the reasons, this decision has brought a significant impact to the Python community, especially to the developers who have dedicated their efforts to improving CPython's performance.

However, looking back at the entire incident, we see both the fragility of the corporate sponsorship model and the strong vitality and self-healing ability of the open source community. The achievements made by the Faster CPython team with Microsoft's support are indelible; they not only substantially increased Python's execution speed but also laid a solid foundation for subsequent performance optimization work. This knowledge and code, contributed in open source form, will become a valuable asset for the community to continue moving forward.

The path ahead may differ from the initial vision, likely relying more on diverse community forces and collaboration among different companies, rather than the strong push from a single giant. But the pursuit of a faster, stronger Python will most likely not stop because of this. This incident also once again presents a classic question to the world: Between commercial interests and the open source spirit, how should large tech companies play their role to achieve truly sustainable win-win outcomes? This is something the entire industry needs to ponder deeply.

References

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

---