From 48a0ff18c63cb33b2c01560b6b72b4993995a200 Mon Sep 17 00:00:00 2001 From: Cornelius Roemer Date: Mon, 22 Sep 2025 08:29:15 +0200 Subject: [PATCH 1/2] Doc: Improve clarity in whatsnew/3.14.rst multiple interpreters section - Change "enables efficiency" to "improves efficiency" - Expand "CSP" to "Communicating Sequential Processes" - Use "are expected to improve" for future tense consistency - Add "new" for clarity in library development expectations --- Doc/whatsnew/3.14.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Doc/whatsnew/3.14.rst b/Doc/whatsnew/3.14.rst index caeff3a00aa049..5d908dd862d6b5 100644 --- a/Doc/whatsnew/3.14.rst +++ b/Doc/whatsnew/3.14.rst @@ -170,16 +170,17 @@ is worth considering: * they support a new (to Python), human-friendly concurrency model * true multi-core parallelism -For some use cases, concurrency in software enables efficiency and -can simplify software, at a high level. At the same time, implementing +For some use cases, concurrency in software improves efficiency and +can simplify software at a high level. At the same time, implementing and maintaining all but the simplest concurrency is often a struggle for the human brain. That especially applies to plain threads (for example, :mod:`threading`), where all memory is shared between all threads. With multiple isolated interpreters, you can take advantage of a class -of concurrency models, like CSP or the actor model, that have found +of concurrency models, like Communicating Sequential Processes +or the actor model, that have found success in other programming languages, like Smalltalk, Erlang, -Haskell, and Go. Think of multiple interpreters like threads +Haskell, and Go. Think of multiple interpreters as threads but with opt-in sharing. Regarding multi-core parallelism: as of the 3.12 release, interpreters @@ -201,7 +202,7 @@ having the isolation of processes with the efficiency of threads. While the feature has been around for decades, multiple interpreters have not been used widely, due to low awareness and the lack of a stdlib module. Consequently, they currently have several notable limitations, -which will improve significantly now that the feature is finally +which are expected to improve significantly now that the feature is going mainstream. Current limitations: @@ -227,7 +228,7 @@ and provide utilities that are less appropriate on PyPI. In the meantime, most of the limitations can also be addressed through extension modules, meaning PyPI packages can fill any gap for 3.14, and even back to 3.12 where interpreters were finally properly isolated and -stopped sharing the :term:`GIL`. Likewise, we expect to slowly see +stopped sharing the :term:`GIL`. Likewise, we expect to slowly see new libraries on PyPI for high-level abstractions on top of interpreters. Regarding extension modules, work is in progress to update some PyPI From ffa85046464f1ef32fa3f9ec470cc23aee9d2d68 Mon Sep 17 00:00:00 2001 From: Adam Turner <9087854+AA-Turner@users.noreply.github.com> Date: Tue, 7 Oct 2025 19:37:22 +0100 Subject: [PATCH 2/2] Update Doc/whatsnew/3.14.rst --- Doc/whatsnew/3.14.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Doc/whatsnew/3.14.rst b/Doc/whatsnew/3.14.rst index 2af3af3130d63c..677365c2f5994b 100644 --- a/Doc/whatsnew/3.14.rst +++ b/Doc/whatsnew/3.14.rst @@ -225,7 +225,7 @@ That especially applies to plain threads (for example, :mod:`threading`), where all memory is shared between all threads. With multiple isolated interpreters, you can take advantage of a class -of concurrency models, like Communicating Sequential Processes +of concurrency models, like Communicating Sequential Processes (CSP) or the actor model, that have found success in other programming languages, like Smalltalk, Erlang, Haskell, and Go. Think of multiple interpreters as threads