Python and Linux Kernel Stories in LWN
-
Kernel Space
-
LWN ☛ The many names of commit 55039832f98c
The kernel is, on its face, a single large development project, but internally it is better viewed as 100 or so semi-independent projects all crammed into one big tent. Within those projects, there is a fair amount of latitude about how changes are managed, and some subsystems are using that freedom in the search for more efficient ways of working. In the end, though, all of these sub-projects have to work together and interface with kernel-wide efforts, including the stable-release and CVE-assignment processes. For some time, there has been friction between the direct rendering (DRM, or graphics) subsystem and the stable maintainers; that friction recently burst into view in a way that shows some of the limitations of how the kernel community manages patches.
One of the key rules for the stable releases is that every patch must first land in the mainline kernel before being considered for the stable trees. The rule exists to ensure that stable patches have had a bare minimum of wider exposure and testing, but also to ensure that no fixes fall through the cracks and miss the mainline entirely. Exceptions to this rule are rare, and usually involve urgent security fixes. In practice, this rule means that any patch proposed for the stable updates should include a line, in its changelog, providing the mainline commit ID for that patch.
-
LWN ☛ Development statistics for 6.13
The 6.13 development cycle ended on January 19 with the release of the 6.13 kernel. This cycle was, on its surface, one of the slowest we have seen in some time; the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 6.13 page can be consulted for a refresher on all it contains. Here, instead, we will take our usual look at where all of those changes came from.
The 6.13 kernel cycle brought in 12,928 non-merge changesets from 2,001 developers. The changeset count is noteworthy for being the lowest since 5.15 (12,377 changesets) in 2021. If one looks at a plot of changeset traffic for each kernel release (taken from the LWN Kernel Source Database), one sees [...]
-
-
Python
-
LWN ☛ A revamped Python string-formatting proposal
The proposal to add a more general facility for string formatting to Python, which we looked at in August 2024, has changed a great deal since, so it merits another look. The changes take multiple forms: a new title for PEP 750 ("Template Strings"), a different mechanism for creating and using templates, a new Template type to hold them, and several additional authors for the PEP. Meanwhile, one controversial part of the original proposal, lazy evaluation of the interpolated values, has been changed so that it requires an explicit opt-in (via lambda); template strings are a generalization of f-strings and lazy evaluation was seen by some as a potentially confusing departure from their behavior.
There are a wide variety of use cases for template strings; the previous title of the PEP referred to creating domain-specific languages using them. Obvious examples are safely handling SQL queries or HTML output with user-supplied input. The PEP also has an example with two different approaches to structured logging using template strings.
-
LWN ☛ Reviving None-aware operators for Python
The idea of adding None-aware operators to Python has sprung up once again. These would make traversing structures with None values in them easier, by short-circuiting lookups when a None is encountered. Almost exactly a year ago, LWN covered the previous attempt to bring the operators to Python, but there have been periodic discussions stretching back to 2015 and possibly before. This time Noah Kim has taken up the cause. After some debate, he eventually settled on redrafting the existing PEP to have a more limited scope, which might finally see it move past the cycle of debate, resurrection, and abandonment that it has been stuck in for most of the last decade.
-