Apply batched suggestions from code review

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

Author: sethmlarson

_typos.toml

@@ -53,5 +53,3 @@ nd = "nd"
 ons = "ons"
 te = "te"
 writeable = "writeable"
-BOCpy = "BOCpy"
-Cpy = "Cpy"  # BOCpy read as 'CPy'?

content/posts/language-summit-2026-developer-in-residence-update-and-future/index.md

@@ -25,7 +25,7 @@ Referencing the explicit “Responding to requests for assistance from core deve
 
 Petr continued with an update on what he’d accomplished from 2024 to 2026, including maintaining [buildbots](https://devguide.python.org/testing/buildbots/), mentoring multiple people into becoming triagers or core developers, working on the [Stable ABI](https://docs.python.org/3/c-api/stable.html) for [free-threaded Python](https://docs.python.org/3/howto/free-threading-python.html), working on security vulnerability fixes, and managing CPython sprints at conferences. He compared this work to what Łukasz had accomplished in his five years of tenure, which included more “large-scale project management”, organizing events like the Language Summit, talking to sponsors, and overseeing the other Python Developers-in-Residence.
 
-Petr summarized his approach to the role as focusing on “important tasks, but leaving fun and glamorous ones to volunteers”. He also noted collaborating with people in other “Developer-in-Residence”-like roles, such as Hugo van Kemenade and Stan Ulbrych, who are Sovereign Tech Agency fellows focusing on CPython. Petr opened the floor for discussion by asking what challenges core developers would like the Developers-in-Residence to focus on.
+Petr summarized his approach to the role as focusing on “important tasks, but leaving fun and glamorous ones to volunteers”. He also noted collaborating with people in other “Developer-in-Residence”-like roles, such as Hugo van Kemenade and Stan Ulbrych, who are [Sovereign Tech Agency fellows](https://www.sovereign.tech/news/meet-the-2026-sovereign-tech-fellows) focusing on CPython. Petr opened the floor for discussion by asking what challenges core developers would like the Developers-in-Residence to focus on.
 
 ## Discussion
 
@@ -39,5 +39,5 @@ Petr confirmed triaging every LLM pull request wasn’t something he wanted to d
 There was some discussion between Stefan Behnel and Mark Shannon about ensuring some amount of review “before a human looks at a pull request”, such as having an LLM provide a first pass on a pull request. Savannah Ostrowski was hesitant to engage with drive-by LLM contributions: “I’m not willing to give away my time because it won’t change their behavior”. She suggested that other core developers “nope out” if they didn’t want to engage.
 
 Mark Shannon recommended everyone [watch Pablo Galindo Salgado’s keynote on this topic](https://www.youtube.com/watch?v=e8uozuvRf7g).
-There is also a Language Summit Lightning Talk by Gregory P. Smith about attempting to
+There is also a Language Summit Lightning Talk by Gregory P. Smith and Łukasz Langa about attempting to
 steer or improve these contributions [using `AGENTS.md`](/2026/09/language-summit-2026-lightning-talks#agentsmd-for-cpython).

content/posts/language-summit-2026-free-threading-post-era/index.md

@@ -7,13 +7,13 @@ tags: [language-summit, language-summit-2026]
 published: true
 ---
 
-Tobias Wrigstad and Fridtjof Stoldt returned to the Python Language Summit, now joined by Donghee Na. Tobias and Fridtjof previously presented “[Fearless Concurrency](https://pyfound.blogspot.com/2025/06/python-language-summit-2025-fearless-concurrency.html)” to the Python Language Summit in 2025. This year the topic at hand was the “post-Free-Threading era of Python”, and what high-level concurrency primitives would be provided by Python.
+Tobias Wrigstad and Fridtjof Stoldt returned to the Python Language Summit, now joined by Donghee Na. Tobias and Fridtjof previously presented “[Fearless Concurrency](https://pyfound.blogspot.com/2025/06/python-language-summit-2025-fearless-concurrency.html)” to the Python Language Summit in 2025. This year the topic at hand was the “post-era of free-threading Python”, and what high-level concurrency primitives would be provided by Python.
 
 ## Comfortable doesn’t mean “Good”
 
 Today the interface for accessing free-threading is, unsurprisingly, “threads”. Threads are how people typically first learn about true parallelism from school, textbooks, and other familiar materials. But what if threads as a user interface aren’t very good? Using threads means users need to care about deadlocks and race conditions.
 
-Python’s free-threading project has made considerable progress since [PEP 779](https://peps.python.org/pep-0779/)’s acceptance. But there was one aspect of PEP 779’s acceptance criteria that hadn’t been addressed yet: high-level concurrency primitives. The complete message from the Steering Council’s acceptance stated:
+Python’s free-threading project has made considerable progress since [PEP 779](https://peps.python.org/pep-0779/)’s acceptance. But there was one aspect of PEP 779’s acceptance criteria that hadn’t been addressed yet: high-level concurrency primitives. The [Steering Council’s acceptance](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319/123) stated:
 
 > Preparation for high-level concurrency primitives. \
 > The Python core team should begin considering and proposing higher-level concurrency primitives that users can use safely and effectively, without requiring a deep understanding of the underlying threading mechanism. And the SC wishes that this task should be prioritized once the above tasks are stable. We recommend using the `concurrent` package in the stdlib for this, where appropriate.
@@ -27,7 +27,7 @@ The talk opened by contrasting approaches to implementing concurrency in differe
 
 C is fast and simple, offering direct access to memory through pointers, which also allows dangerous and unsafe operations; C relies on programmer discipline for program correctness. Erlang has multiple threads, but to communicate, data is copied over to the other “actor”, so it’s safe and simple, but performance suffers. Rust is performant and safe, but it’s not simple: “you’ll find yourself often fighting with the [borrow checker](https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html)”.
 
-![](image.png)
+![What do we want for concurrency in Python? Triangle with corners labeled safety, performance and simplicity. C is fast + simple, Erlang is safe + simple, Rust is fast + safe.](image.png)
 
 “Where would we put Python on this triangle?”
 
@@ -49,9 +49,6 @@ Some examples of programs written using locks and threads were then transformed
 
 There are [many more examples available on GitHub](https://github.com/microsoft/bocpy/tree/main/examples). This proof of concept, implemented using subinterpreters, is available for anyone to try: [bocpy](https://microsoft.github.io/bocpy), available on the [Python Package Index](https://pypi.org/project/bocpy):
 
-```commandline
-$ python -m pip install bocpy
-```
 
 Checking bocpy against their own criteria of simplicity, safety, and performance: bocpy is simple, as can be seen in the above examples. On the safety front, bocpy today runs in “stable Python”, and for this reason only isolation has been implemented so far. “We don’t yet have ownership, you can’t implement [ownership] as a third-party library”, as this would require changes to the runtime. Performance is “good for programs that aren’t communication dominated” due to “communication being expensive for subinterpreters”.
 
@@ -61,15 +58,15 @@ The bocpy package provides three features:
 * [Behaviors](https://microsoft.github.io/bocpy/#behaviors) (the tasks spawned with `@when` decorators)
 * Scheduler (implemented with subinterpreters, with planned support for free-threading)
 
-Looking forward, the three have two other proofs of concept that modify the Python runtime “to allow for safe concurrency and create safe abstractions while keeping performance”. The first implements isolation by organizing the heap into isolated groups of objects, where ownership violations would raise an exception from Cowns. The second is for immutability of Python objects ([PEP 795](https://peps.python.org/pep-0795/)).
+Looking forward, the three have two other proofs of concept that modify the Python runtime “to allow for safe concurrency and create safe abstractions while keeping performance”. The first implements isolation by organizing the heap into isolated groups of objects, where ownership violations would raise an exception from Cowns. The second is for immutability of Python objects ([PEP 795](https://github.com/python/peps/pull/4468)).
 
 The group made it clear that changes to core Python would be needed to support safe concurrency, asking whether Python would trade “some performance for safety”. What primitives do we want to provide in the standard library; are locks enough? And if we do provide primitives, should they be something like bocpy?
 
 ## Discussion
 
 Thomas Wouters recalled that the core team “has experience trying to create universal interfaces for subprocesses, multiprocessing, threading”. In practice, there are always corner cases, and performance is suboptimal because of the constraints of the APIs. Thomas asked “how confident [the three] are that this isn’t the case for bocpy?” The three shared Thomas’s concern. “This is a question we’re working on”, answered Fridtjof. “If you have [the bocpy] ownership model it’s possible to treat subinterpreters and threads similarly, you can have communication, and you can share objects directly with the ownership model”.
 
-“Notion of tasks and schedulers immediately brings async to my head”, David Hewitt said, wondering “how does async fit into this picture?” He asked the trio whether bocpy “should be built on [`asyncio`](https://docs.python.org/3/library/asyncio.html)” and have “async mutex primitives instead of being [synchronous]”. Tobias confirmed that bocpy “could be” built using `asyncio`: “it depends on what backend infrastructure” is used and the trade-offs of each backend. “If you want to do some I/O, you tell the I/O library to put something into a Cown once data is available and schedule a task to run when the data is available to avoid blocking”.
+“Notion of tasks and schedulers immediately brings async to my head”, David Hewitt said, wondering “how does async fit into this picture?” He asked the trio whether bocpy “should be built on [`asyncio`](https://docs.python.org/3/library/asyncio.html)” and have “async mutex primitives instead of being [synchronous]”. Tobias confirmed that bocpy “could be” built using `asyncio`: “it depends on what backend infrastructure” is used and the trade-offs of each backend. “If you want to do some I/O, you tell the I/O library to put something into a cown once data is available and schedule a task to run when the data is available to avoid blocking”.
 
 Larry Hastings was “happy to see this research going on” and welcomed more from the group, but didn’t see bocpy or any singular solution as “the” method to do concurrency in Python. “[Larry] would like Python to have all the tools that give you and other groups with competing ideas the ability to implement ideas and provide them to users”. Instead, Larry was wary of “anointing a single way”, to avoid locking Python into a particular implementation in case better options are discovered later. Donghee shared that the group wasn’t initially trying to force a single way, only to start the conversation.
 

content/posts/language-summit-2026-garbage-collection-generational-incremental-both/index.md

@@ -11,7 +11,7 @@ The third Language Summit talk was brought by Mark Shannon, who is the author of
 
 Mark’s talk opened with a graph about where Python spends its time, split between the interpreter, lookups, modules, and the focus of the talk: garbage collection, which takes around 11.67% of execution time. Mark remarked that even if the [Just-in-Time (JIT) compiler](https://peps.python.org/pep-0744/) makes the interpreter faster (representing 30.6% of time), we’ll unfortunately still have to worry about memory management and garbage collection to make the runtime faster: Mark’s talk was about minimizing the time spent doing these tasks.
 
-![](image.svg)
+![Pie chart of where Python spends its time: interpreter 30.60%, memory 11.89%, gc 11.67%, lookup 8.88%, dynamic 4.91%, dict 3.86%, tuple 3.33%, int 3.30%, str 2.39%, smaller ones unlabelled](image.svg)
 
 What does Python’s garbage collector do today? Funnily enough, this ~12% of time spent is not Python’s primary garbage collection mechanism; [reference counting](https://docs.python.org/3/glossary.html#term-reference-count) is. The garbage collector is a “backup” and “should be much faster”. Reference counting is already collecting dead objects, therefore the garbage collector should only have to find dead unreachable cycles.
 
@@ -20,7 +20,7 @@ Mark emphasized pause times during garbage collection, a metric which the increm
 So how would we know whether we’ve improved the garbage collector? Mark defined a term “effectiveness” along with other definitions that will be useful for thinking about different approaches to garbage collection:
 
 * **Scavenge**: This is the minimal garbage collector operation. Give the garbage collector a set of objects and all unreachable cycles are collected. At a high level, users don’t have to worry about how the garbage collector accomplishes this task.
-* **Scavenge Effectiveness**: This is the metric being optimized for, calculated as “objects collected” divided by the “number of objects visited”. The effectiveness of the two Python garbage collectors is “pretty poor”, with the old generational GC at 0.3% effectiveness and the reverted incremental GC at ~1% effectiveness.
+* **Scavenge Effectiveness**: This is the metric being optimized for, calculated as “objects collected” divided by the “number of objects visited”. The effectiveness of the two Python garbage collectors is “pretty poor”, with the generational GC at 0.3% effectiveness and the reverted incremental GC at ~1% effectiveness.
 * **Generational hypothesis**: The assumption that “most objects die young”, which garbage collectors can use to be more effective. However, the exact profile depends on the program being executed.
 * **Spaces**: Grouping of objects that are consecutively allocated. All new objects are added to the newest “space”. Spaces have a defined size, and once they are full, the GC can begin scavenging the space and a new empty space is created for newly created objects to be added to. The period when spaces are closed to new objects is a good opportunity to scavenge, as no scavenge operations can occur on an open space.
 * **Generation**: A group of consecutive spaces. Generations are much fewer than spaces and typically baked into the garbage collector. Spaces only move in one direction through generations.
@@ -32,6 +32,7 @@ Mark then turned to explaining the now-reverted incremental garbage collector. T
 ## Can we have the best of both worlds?
 
 Generational garbage collectors have lower memory usage overall but suffer from higher pause times, whereas incremental garbage collectors pause for less time but at the expense of more memory. What should Python do as a default?
+
 Mark’s final proposal included how he’d interleave the concepts of generational and incremental garbage collectors to achieve the best of both:
 
 * Two generations: one “young” and one “old”.
@@ -43,7 +44,7 @@ Donghee Na was concerned that any changes to the garbage collector would cause i
 
 Donghee asked whether configuration options similar to what is available for [JVM garbage collectors](https://docs.oracle.com/en/java/javase/21/gctuning/) could be made available so users could tweak settings to fit their needs. Mark didn’t think this should be necessary; in JVM languages the GC is “the whole thing”, compared to Python where GC is only the “backup” behind reference counting.
 
-Jukka signaled his interest in helping Mark and asked about existing applications that had fine-tuned their GC, noting that these fine-tunings “go stale” whenever the GC changes, even if the new GC is better on average. Mark hoped that if done correctly, Python could remove the need to fine-tune GCs.
+Jukka Lehtosalo signaled his interest in helping Mark and asked about existing applications that had fine-tuned their GC, noting that these fine-tunings “go stale” whenever the GC changes, even if the new GC is better on average. Mark hoped that if done correctly, Python could remove the need to fine-tune GCs.
 
 Gregory P. Smith lamented that adding [public APIs for the garbage collector](https://docs.python.org/3/library/gc.html) and allowing fine-tuning inhibits being able to improve the general case. Greg also didn’t want to support multiple GC implementations like the JVM does. Greg’s biggest takeaway from the incremental GC revert in Python 3.14 is that there are use-cases which are served well by one GC and not by another, and “those cases should be in our test suite”.
 

content/posts/language-summit-2026-lightning-talks/index.md

@@ -81,11 +81,11 @@ By Kushal Das
 
 Kushal Das brought a short presentation on a project he’d been working on to teach Python to the generation of young programmers who learned using Scratch. [Scratch](https://scratch.mit.edu/) is a programming language that is represented using blocks instead of text to create animations, games, and other media-focused programs.
 
-EktuPy brings many of the features that are beloved in Scratch, such as the focus on media like games and animations, and the “remix” concept to give new programmers a working base to start with instead of a daunting blank canvas. EktuPy tries to bridge the gap between block-based programming languages and text-based languages like Python.
+[EktuPy](https://ektupy.org) brings many of the features that are beloved in Scratch, such as the focus on media like games and animations, and the “remix” concept to give new programmers a working base to start with instead of a daunting blank canvas. EktuPy tries to bridge the gap between block-based programming languages and text-based languages like Python.
 
 ## AGENTS.md for CPython
 
-By Gregory P. Smith
+By Gregory P. Smith and Łukasz Langa
 
 CPython, just like many other open source projects, has been seeing many contributions from folks using LLM agents. Gregory P. Smith and Łukasz Langa wanted to get a “vibe check” from core developers about adding a simple `AGENTS.md` file to the CPython repository. The hope was that even basic guidance about how to contribute to CPython (such as linking to the [Developer Guide](https://devguide.python.org/)) would improve the quality of the large number of pull requests made using agents.
 

content/posts/language-summit-2026-macos-python/index.md

@@ -41,6 +41,7 @@ Ned listed a few other projects which build and distribute Python for macOS, inc
 ## What’s next?
 
 Ned closed the topic by listing his plans for macOS and Python. He noted that there was no section for macOS in [PEP 11](https://peps.python.org/pep-0011/), the PEP which details platform support for CPython, [whereas there was a section for Windows](https://peps.python.org/pep-0011/#microsoft-windows). He planned to propose such a section for macOS and get feedback from other core developers. More generally, Ned wanted a policy for “supporting macOS in general”, covering people who want to build Python themselves and detailing what is supported.
+
 Currently, all three build types and architectures are considered the same in terms of “support” in PEP 11. Ned wondered whether each of these builds should be treated as a different PEP 11 target. This would allow macOS on ARM to be in a different support tier from macOS on x86-64. Ned would also like to leverage the large overlap in building and packaging for iOS and macOS.
 
 Ned would like to automate the build process, including the packaging and continuous integration, much like Windows already has as a part of the Python release process. In addition, Ned wants to modernize Python’s macOS support, including deprecating and removing the PPC universal builds and migrating to [XCFramework](https://developer.apple.com/documentation/xcode/creating-a-multi-platform-binary-framework-bundle) packaging instead of the legacy Framework format. “We’ve got a lot of cruft”.