From 81bb9dc3aa36bb304c962eb71d3b468c4fd54518 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 10 Mar 2025 17:45:54 +0100 Subject: [PATCH 01/14] Initial draft of PEP 703 phase II promotion requirements. --- peps/pep-0780.rst | 172 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 peps/pep-0780.rst diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst new file mode 100644 index 00000000000..442881288a9 --- /dev/null +++ b/peps/pep-0780.rst @@ -0,0 +1,172 @@ +PEP: 0780 +Title: Criteria for supported status for free-threaded Python +Author: Thomas Wouters +Status: Draft +Type: Standards Track +Created: 3-Feb-2025 +Python-Version: 3.14 + + +Abstract +======== + +The acceptance of :pep:`703`, as `announced by the Steering Council +`__, +describes three phases of development for the work to remove the Global +Interpreter Lock. Phase I started early in the development of Python 3.13, +and includes making the free-threaded (GIL-less) Python build available but +explicitly *experimental*. Phase II would make the free-threaded build +officially supported but still optional, and phase III would make the +free-threaded build the default. Because of the number of unknowns at the +time, the criteria for moving to the next phase were left deliberately vague +at the time. This PEP establishes clear expectations and requirements for +moving to Phase II, making the free-threaded Python build officially +supported. + + .. note:: + + Eagle-eyed readers may have noticed an overlap in authors of this PEP and + the Steering Council at the time of PEP 703 acceptance. The SC makeup has + since changed, but just to make it explicit: this PEP as proposed, while + based on criteria set forth by the SC, does not come from the Steering + Council itself. + +Motivation +========== + +Whether to move forward with :pep:`703` (as well as ultimately making it the +default) is a question of whether the costs outweigh the benefits. Making +free-threaded Python an officially supported build is important to signal +that we're now at a stage where the design is finalised, the APIs are usable +and stable, and we're satisfied the performance and complexity cost is not +prohibitive. + +Moving to the "officially supported" stage is an important step towards +making free-threaded Python the default build, and eventually the only one. +Before we can decide we're ready to make it the default, we need a much +better picture of the costs and the benefits, and we can only get there if +more of the Python ecosystem starts supporting free-threaded Python. We +currently have enough packages and tools supporting :pep:`703` that it's +clear we're on the right path, but not enough to make the final decision. In +addition to giving the Python community time to make the changes necessary +to support free-threaded Python, we expect to use phase II to show clear +benefits in real-world applications, as well as clearly define the cost in +terms of performance, support burden, and ecosystem complexity. + +Rationale +========= + +In order for PEP 703 to be acceptable it should be desireable, stable, +maintainable, performant (in CPU and memory), and ideally it should have +Stable ABI so the same wheels can be used for free-threaded and with-GIL +builds. + + - Desirability: from various experiments it's very clear free-threaded + Python has tremendous potential benefit. It's not a simple drop-in + solution -- code will have to be rewritten to make the most of the new + capability, as well as avoid performance pitfalls -- but it can achieve + higher performance, significantly lower latency and new thread-based + functionality when embraced. + + - Stability: the majority of the new API design is in 3.13, and is being + succesfully used to support free-threaded Python in a number of + third-party packages (see for example + https://py-free-threading.github.io/tracking/). There's been some more + development in 3.14 to add more conveniency functions, and to replace + APIs that previously relied on the GIL for thread-safety, but we have not + had to break the 3.13 APIs for free-threaded Python. + + - Maintainability: the majority of :pep:`703`'s design is relatively + simple, with most complexity hidden away behind CPython's existing C + APIs. The implementation details of, for example, lockless list and dict + APIs, `which rely on QSBR `_, + and `deadlock-avoiding critical sections `_, + may be complex and difficult to get right, but gives us easy to use APIs + without too many pitfalls. Making more of CPython free-threading-safe is + a relatively simple process, although we do probably need more + documentation on the basic guarantees the new APIs provide + (https://github.com/python/cpython/issues/128642). + + - Performance: the performance penalty on linear performance, comparing a + free-threaded build against a with-GIL build, as measured by the + pyperformance benchmarks (for example as run by `Microsoft's Faster + CPython team `_, + or `Meta's Python Runtime team `_), + is currently around 10% (except on macOS, where it's more like 3%). We + have a few more PRs in flight that should get us comfortably below 10% on + Linux and Windows. + + - Memory use. Exact numbers vary because of the different gc module + implementation, but free-threaded Python currently sees about 15-20% + higher memory use (geometric mean, as measured by pyperformance). We + haven't spent a lot of time trying to lower this yet, so we may be able + to push this down further. Realistically, though, higher memory use is + the cost of having efficient, safe free-threading, and we are unlikely to + get this close to the with-GIL build's memory use without significant + performance cost. + + - Stable ABI. Stable ABI support is mentioned by the Steering Council as a + potential requirement for phase II. While having Stable ABI support would + make third-party package distribution a lot easier, there's a bit of a + chicken and egg problem: we don't know if the Stable ABI is good enough + if we don't have packages that support free-threaded Python using it, and + we can't remove things from the Stable ABI if we discover problems with + them. Given that phase II is meant to give the community time to adopt + free-threaded Python and provide feedback on APIs and ABIs, we're not + sure how strong a requirement the Stable ABI should be for phase II. + + +Specification +============= + +Specific criteria for making free-threaded Python officially supported +(phase II), as we propose them: + + - Acceptable performance. The Steering Council mentioned they expected + free-threaded Python to be around 10-15% slower, although this was not a + hard target. We are currently around 10% and don't expect it to get + slower, but for phase II (not the default flip), we propose 15% as a hard performance target. + + - Acceptable memory use. This was not mentioned by the Steering Council and + hasn't seen much discussion. We propose a target of 20% (geometric mean, + as measured by pyperformance) for phase II. For phase III, we'll need + input from the community as to where the trade-off between memory and CPU + performance should end up. + + - Proven APIs. This is a difficult thing to measure, but we have seen + significant adoption of free-threaded Python with the existing APIs, and + have not had to radically change any existing APIs to accomodate them. We + will probably end up adding some more conveniency APIs for specific + use-cases in the future, but we believe we have proven the viability of + the APIs we have. + + - Internal documentation. We have multiple Core Developers working on + free-threaded Python, including several who recently started working on + fixing thread-safety issues in specific modules, but we probably need to + shore up the introductory documentation for the internals of + free-threaded Python. This should not be a problem to achieve for 3.14. + +With these criteria satisfied, we believe Python 3.14 is the right time frame +for phase II of :pep:`703`. + +(Note that these are requirements for entering phase II *only*. The decision +to make free-threaded Python the default (phase III) is very different, and +we expect it will revolve around community support, willingness, and showing +clear benefit.) + + +Open Issues +=========== + +- Should the Stable ABI be a strong requirement for "supported" status of the free-threaded build? + + +Footnotes +========= + +Copyright +========= + +This document is placed in the public domain or under the +CC0-1.0-Universal license, whichever is more permissive. + From 9c56720643bd4ddda1a6e65b6cfaaedcb93b2ba4 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 10 Mar 2025 17:51:37 +0100 Subject: [PATCH 02/14] Markup fixes. --- peps/pep-0780.rst | 164 +++++++++++++++++++++++----------------------- 1 file changed, 82 insertions(+), 82 deletions(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index 442881288a9..3c5c53257d8 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -23,13 +23,13 @@ at the time. This PEP establishes clear expectations and requirements for moving to Phase II, making the free-threaded Python build officially supported. - .. note:: +.. note:: - Eagle-eyed readers may have noticed an overlap in authors of this PEP and - the Steering Council at the time of PEP 703 acceptance. The SC makeup has - since changed, but just to make it explicit: this PEP as proposed, while - based on criteria set forth by the SC, does not come from the Steering - Council itself. + Eagle-eyed readers may have noticed an overlap in authors of this PEP and + the Steering Council at the time of PEP 703 acceptance. The SC makeup has + since changed, but just to make it explicit: this PEP as proposed, while + based on criteria set forth by the SC, does not come from the Steering + Council itself. Motivation ========== @@ -61,59 +61,59 @@ maintainable, performant (in CPU and memory), and ideally it should have Stable ABI so the same wheels can be used for free-threaded and with-GIL builds. - - Desirability: from various experiments it's very clear free-threaded - Python has tremendous potential benefit. It's not a simple drop-in - solution -- code will have to be rewritten to make the most of the new - capability, as well as avoid performance pitfalls -- but it can achieve - higher performance, significantly lower latency and new thread-based - functionality when embraced. - - - Stability: the majority of the new API design is in 3.13, and is being - succesfully used to support free-threaded Python in a number of - third-party packages (see for example - https://py-free-threading.github.io/tracking/). There's been some more - development in 3.14 to add more conveniency functions, and to replace - APIs that previously relied on the GIL for thread-safety, but we have not - had to break the 3.13 APIs for free-threaded Python. - - - Maintainability: the majority of :pep:`703`'s design is relatively - simple, with most complexity hidden away behind CPython's existing C - APIs. The implementation details of, for example, lockless list and dict - APIs, `which rely on QSBR `_, - and `deadlock-avoiding critical sections `_, - may be complex and difficult to get right, but gives us easy to use APIs - without too many pitfalls. Making more of CPython free-threading-safe is - a relatively simple process, although we do probably need more - documentation on the basic guarantees the new APIs provide - (https://github.com/python/cpython/issues/128642). - - - Performance: the performance penalty on linear performance, comparing a - free-threaded build against a with-GIL build, as measured by the - pyperformance benchmarks (for example as run by `Microsoft's Faster - CPython team `_, - or `Meta's Python Runtime team `_), - is currently around 10% (except on macOS, where it's more like 3%). We - have a few more PRs in flight that should get us comfortably below 10% on - Linux and Windows. - - - Memory use. Exact numbers vary because of the different gc module - implementation, but free-threaded Python currently sees about 15-20% - higher memory use (geometric mean, as measured by pyperformance). We - haven't spent a lot of time trying to lower this yet, so we may be able - to push this down further. Realistically, though, higher memory use is - the cost of having efficient, safe free-threading, and we are unlikely to - get this close to the with-GIL build's memory use without significant - performance cost. - - - Stable ABI. Stable ABI support is mentioned by the Steering Council as a - potential requirement for phase II. While having Stable ABI support would - make third-party package distribution a lot easier, there's a bit of a - chicken and egg problem: we don't know if the Stable ABI is good enough - if we don't have packages that support free-threaded Python using it, and - we can't remove things from the Stable ABI if we discover problems with - them. Given that phase II is meant to give the community time to adopt - free-threaded Python and provide feedback on APIs and ABIs, we're not - sure how strong a requirement the Stable ABI should be for phase II. +- Desirability: from various experiments it's very clear free-threaded + Python has tremendous potential benefit. It's not a simple drop-in + solution -- code will have to be rewritten to make the most of the new + capability, as well as avoid performance pitfalls -- but it can achieve + higher performance, significantly lower latency and new thread-based + functionality when embraced. + +- Stability: the majority of the new API design is in 3.13, and is being + succesfully used to support free-threaded Python in a number of + third-party packages (see for example + https://py-free-threading.github.io/tracking/). There's been some more + development in 3.14 to add more conveniency functions, and to replace + APIs that previously relied on the GIL for thread-safety, but we have not + had to break the 3.13 APIs for free-threaded Python. + +- Maintainability: the majority of :pep:`703`'s design is relatively + simple, with most complexity hidden away behind CPython's existing C + APIs. The implementation details of, for example, lockless list and dict + APIs, `which rely on QSBR `_, + and `deadlock-avoiding critical sections `_, + may be complex and difficult to get right, but gives us easy to use APIs + without too many pitfalls. Making more of CPython free-threading-safe is + a relatively simple process, although we do probably need more + documentation on the basic guarantees the new APIs provide + (https://github.com/python/cpython/issues/128642). + +- Performance: the performance penalty on linear performance, comparing a + free-threaded build against a with-GIL build, as measured by the + pyperformance benchmarks (for example as run by `Microsoft's Faster + CPython team `_, + or `Meta's Python Runtime team `_), + is currently around 10% (except on macOS, where it's more like 3%). We + have a few more PRs in flight that should get us comfortably below 10% on + Linux and Windows. + +- Memory use. Exact numbers vary because of the different gc module + implementation, but free-threaded Python currently sees about 15-20% + higher memory use (geometric mean, as measured by pyperformance). We + haven't spent a lot of time trying to lower this yet, so we may be able + to push this down further. Realistically, though, higher memory use is + the cost of having efficient, safe free-threading, and we are unlikely to + get this close to the with-GIL build's memory use without significant + performance cost. + +- Stable ABI. Stable ABI support is mentioned by the Steering Council as a + potential requirement for phase II. While having Stable ABI support would + make third-party package distribution a lot easier, there's a bit of a + chicken and egg problem: we don't know if the Stable ABI is good enough + if we don't have packages that support free-threaded Python using it, and + we can't remove things from the Stable ABI if we discover problems with + them. Given that phase II is meant to give the community time to adopt + free-threaded Python and provide feedback on APIs and ABIs, we're not + sure how strong a requirement the Stable ABI should be for phase II. Specification @@ -122,29 +122,29 @@ Specification Specific criteria for making free-threaded Python officially supported (phase II), as we propose them: - - Acceptable performance. The Steering Council mentioned they expected - free-threaded Python to be around 10-15% slower, although this was not a - hard target. We are currently around 10% and don't expect it to get - slower, but for phase II (not the default flip), we propose 15% as a hard performance target. - - - Acceptable memory use. This was not mentioned by the Steering Council and - hasn't seen much discussion. We propose a target of 20% (geometric mean, - as measured by pyperformance) for phase II. For phase III, we'll need - input from the community as to where the trade-off between memory and CPU - performance should end up. - - - Proven APIs. This is a difficult thing to measure, but we have seen - significant adoption of free-threaded Python with the existing APIs, and - have not had to radically change any existing APIs to accomodate them. We - will probably end up adding some more conveniency APIs for specific - use-cases in the future, but we believe we have proven the viability of - the APIs we have. - - - Internal documentation. We have multiple Core Developers working on - free-threaded Python, including several who recently started working on - fixing thread-safety issues in specific modules, but we probably need to - shore up the introductory documentation for the internals of - free-threaded Python. This should not be a problem to achieve for 3.14. +- Acceptable performance. The Steering Council mentioned they expected + free-threaded Python to be around 10-15% slower, although this was not a + hard target. We are currently around 10% and don't expect it to get + slower, but for phase II (not the default flip), we propose 15% as a hard performance target. + +- Acceptable memory use. This was not mentioned by the Steering Council and + hasn't seen much discussion. We propose a target of 20% (geometric mean, + as measured by pyperformance) for phase II. For phase III, we'll need + input from the community as to where the trade-off between memory and CPU + performance should end up. + +- Proven APIs. This is a difficult thing to measure, but we have seen + significant adoption of free-threaded Python with the existing APIs, and + have not had to radically change any existing APIs to accomodate them. We + will probably end up adding some more conveniency APIs for specific + use-cases in the future, but we believe we have proven the viability of + the APIs we have. + +- Internal documentation. We have multiple Core Developers working on + free-threaded Python, including several who recently started working on + fixing thread-safety issues in specific modules, but we probably need to + shore up the introductory documentation for the internals of + free-threaded Python. This should not be a problem to achieve for 3.14. With these criteria satisfied, we believe Python 3.14 is the right time frame for phase II of :pep:`703`. From aae731053cbdb1048ac950818687b74ae5a492ba Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 10 Mar 2025 18:06:54 +0100 Subject: [PATCH 03/14] Markup fixes. --- peps/pep-0780.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index 3c5c53257d8..8773279d522 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -114,7 +114,6 @@ builds. them. Given that phase II is meant to give the community time to adopt free-threaded Python and provide feedback on APIs and ABIs, we're not sure how strong a requirement the Stable ABI should be for phase II. - Specification ============= From 74d1b87d1d45f793d4abd922a8cc151d02db036d Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 10 Mar 2025 18:32:13 +0100 Subject: [PATCH 04/14] Markup fixes. --- peps/pep-0780.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index 8773279d522..6b1115857ca 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -1,4 +1,4 @@ -PEP: 0780 +PEP: 780 Title: Criteria for supported status for free-threaded Python Author: Thomas Wouters Status: Draft From 2fcba50755659d0d47209404f69d4938a6366f32 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 10 Mar 2025 18:32:32 +0100 Subject: [PATCH 05/14] More markup fixes, because why not. --- peps/pep-0780.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index 6b1115857ca..4d5f1986a48 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -3,7 +3,7 @@ Title: Criteria for supported status for free-threaded Python Author: Thomas Wouters Status: Draft Type: Standards Track -Created: 3-Feb-2025 +Created: 03-Feb-2025 Python-Version: 3.14 From 62eb654e218197bff56958e3c259278e4a140a02 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 10 Mar 2025 18:32:58 +0100 Subject: [PATCH 06/14] Fix a few more lint issues. --- peps/pep-0780.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index 4d5f1986a48..ff91f46b7aa 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -153,7 +153,6 @@ to make free-threaded Python the default (phase III) is very different, and we expect it will revolve around community support, willingness, and showing clear benefit.) - Open Issues =========== @@ -168,4 +167,3 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - From bce15aa3a7185d09a58cc5edc1df9ac8114a7ac7 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Tue, 11 Mar 2025 01:04:36 +0100 Subject: [PATCH 07/14] Spelling fixes courtesy of mpage. --- peps/pep-0780.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index ff91f46b7aa..14aea6de91b 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -56,7 +56,7 @@ terms of performance, support burden, and ecosystem complexity. Rationale ========= -In order for PEP 703 to be acceptable it should be desireable, stable, +In order for PEP 703 to be acceptable it should be desirable, stable, maintainable, performant (in CPU and memory), and ideally it should have Stable ABI so the same wheels can be used for free-threaded and with-GIL builds. @@ -69,10 +69,10 @@ builds. functionality when embraced. - Stability: the majority of the new API design is in 3.13, and is being - succesfully used to support free-threaded Python in a number of + successfully used to support free-threaded Python in a number of third-party packages (see for example https://py-free-threading.github.io/tracking/). There's been some more - development in 3.14 to add more conveniency functions, and to replace + development in 3.14 to add more convenience functions, and to replace APIs that previously relied on the GIL for thread-safety, but we have not had to break the 3.13 APIs for free-threaded Python. @@ -134,8 +134,8 @@ Specific criteria for making free-threaded Python officially supported - Proven APIs. This is a difficult thing to measure, but we have seen significant adoption of free-threaded Python with the existing APIs, and - have not had to radically change any existing APIs to accomodate them. We - will probably end up adding some more conveniency APIs for specific + have not had to radically change any existing APIs to accommodate them. We + will probably end up adding some more convenience APIs for specific use-cases in the future, but we believe we have proven the viability of the APIs we have. From 94c89028e667a70977b6ddf881dce7ad7ff0ded7 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Wed, 12 Mar 2025 16:10:23 +0100 Subject: [PATCH 08/14] Update based on feedback. --- peps/pep-0780.rst | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index 14aea6de91b..9329bef98d8 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -10,7 +10,8 @@ Python-Version: 3.14 Abstract ======== -The acceptance of :pep:`703`, as `announced by the Steering Council +The acceptance of :pep:`703` (Making the Global Interpreter Lock Optional in +CPython), as `announced by the Steering Council `__, describes three phases of development for the work to remove the Global Interpreter Lock. Phase I started early in the development of Python 3.13, @@ -63,10 +64,10 @@ builds. - Desirability: from various experiments it's very clear free-threaded Python has tremendous potential benefit. It's not a simple drop-in - solution -- code will have to be rewritten to make the most of the new - capability, as well as avoid performance pitfalls -- but it can achieve - higher performance, significantly lower latency and new thread-based - functionality when embraced. + solution -- some code will have to be redesigned to make the most of the + new capability, as well as avoid performance pitfalls -- but it can + achieve higher performance, significantly lower latency and new + thread-based functionality when embraced. - Stability: the majority of the new API design is in 3.13, and is being successfully used to support free-threaded Python in a number of @@ -99,10 +100,10 @@ builds. - Memory use. Exact numbers vary because of the different gc module implementation, but free-threaded Python currently sees about 15-20% higher memory use (geometric mean, as measured by pyperformance). We - haven't spent a lot of time trying to lower this yet, so we may be able - to push this down further. Realistically, though, higher memory use is - the cost of having efficient, safe free-threading, and we are unlikely to - get this close to the with-GIL build's memory use without significant + haven't spent a lot of time trying to lower this yet, so we may be able to + push this down further. Realistically, though, higher memory use is the + cost of having efficient, safe free-threading, and we are unlikely to get + this very close to the with-GIL build's memory use without significant performance cost. - Stable ABI. Stable ABI support is mentioned by the Steering Council as a @@ -136,8 +137,10 @@ Specific criteria for making free-threaded Python officially supported significant adoption of free-threaded Python with the existing APIs, and have not had to radically change any existing APIs to accommodate them. We will probably end up adding some more convenience APIs for specific - use-cases in the future, but we believe we have proven the viability of - the APIs we have. + use-cases in the future, but we believe we have proven the viability and + stability of the APIs we have. We have not needed significant breaking + changes in new APIs, and we expect all future changes to follow + :pep:`387`'s change policy. - Internal documentation. We have multiple Core Developers working on free-threaded Python, including several who recently started working on From 8c3b8fe729f4e29ccfe29ba52e5b324fd25d028e Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Wed, 12 Mar 2025 16:12:15 +0100 Subject: [PATCH 09/14] Slight elaboration. --- peps/pep-0780.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index 9329bef98d8..f045d3a22bc 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -133,14 +133,14 @@ Specific criteria for making free-threaded Python officially supported input from the community as to where the trade-off between memory and CPU performance should end up. -- Proven APIs. This is a difficult thing to measure, but we have seen - significant adoption of free-threaded Python with the existing APIs, and - have not had to radically change any existing APIs to accommodate them. We - will probably end up adding some more convenience APIs for specific - use-cases in the future, but we believe we have proven the viability and - stability of the APIs we have. We have not needed significant breaking - changes in new APIs, and we expect all future changes to follow - :pep:`387`'s change policy. +- Proven, stable APIs. This is a difficult thing to measure, but we have + seen significant adoption of free-threaded Python with the existing APIs, + and have not had to radically change any existing APIs to accommodate + them. We will probably end up adding some more convenience APIs for + specific use-cases in the future, but we believe we have proven the + viability and stability of the APIs we have. We have not needed + significant breaking changes in new APIs, and we expect all future changes + to follow :pep:`387`'s change policy. - Internal documentation. We have multiple Core Developers working on free-threaded Python, including several who recently started working on From 76495c15a18575b47ebad8c80f0611040d34303e Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Wed, 12 Mar 2025 16:20:08 +0100 Subject: [PATCH 10/14] Add co-authors. --- peps/pep-0780.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index f045d3a22bc..da9490dfe76 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -1,6 +1,6 @@ PEP: 780 Title: Criteria for supported status for free-threaded Python -Author: Thomas Wouters +Author: Thomas Wouters , Matt Page , Sam Gross Status: Draft Type: Standards Track Created: 03-Feb-2025 From 0d8e1af7be4f28aae2e172ad588e182ec7c13ba0 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Wed, 12 Mar 2025 16:29:26 +0100 Subject: [PATCH 11/14] Reformat a little. --- peps/pep-0780.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index da9490dfe76..fef61cca948 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -1,6 +1,8 @@ PEP: 780 Title: Criteria for supported status for free-threaded Python -Author: Thomas Wouters , Matt Page , Sam Gross +Author: Thomas Wouters , + Matt Page , + Sam Gross Status: Draft Type: Standards Track Created: 03-Feb-2025 From a9f13796bf1cb62e26451e1389767eebe66c8894 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Thu, 13 Mar 2025 01:26:05 +0100 Subject: [PATCH 12/14] Minor language changes. --- peps/pep-0780.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst index fef61cca948..01b9e0269e7 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0780.rst @@ -141,7 +141,7 @@ Specific criteria for making free-threaded Python officially supported them. We will probably end up adding some more convenience APIs for specific use-cases in the future, but we believe we have proven the viability and stability of the APIs we have. We have not needed - significant breaking changes in new APIs, and we expect all future changes + breaking changes in new APIs, and we expect all future changes to follow :pep:`387`'s change policy. - Internal documentation. We have multiple Core Developers working on @@ -156,7 +156,7 @@ for phase II of :pep:`703`. (Note that these are requirements for entering phase II *only*. The decision to make free-threaded Python the default (phase III) is very different, and we expect it will revolve around community support, willingness, and showing -clear benefit.) +clear benefit. That's left for a future PEP.) Open Issues =========== From 4b2d899966fcc4328048dcff4d72386462a2c499 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Thu, 13 Mar 2025 01:33:26 +0100 Subject: [PATCH 13/14] Rename to lowest available number. --- peps/{pep-0780.rst => pep-0779.rst} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename peps/{pep-0780.rst => pep-0779.rst} (99%) diff --git a/peps/pep-0780.rst b/peps/pep-0779.rst similarity index 99% rename from peps/pep-0780.rst rename to peps/pep-0779.rst index 01b9e0269e7..563a2c7dabb 100644 --- a/peps/pep-0780.rst +++ b/peps/pep-0779.rst @@ -1,4 +1,4 @@ -PEP: 780 +PEP: 779 Title: Criteria for supported status for free-threaded Python Author: Thomas Wouters , Matt Page , From 47604876003c351545ebd8f71ea4a2e849e5cba6 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Thu, 13 Mar 2025 12:45:12 +0100 Subject: [PATCH 14/14] Use Matt's shiny new email address. --- peps/pep-0779.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0779.rst b/peps/pep-0779.rst index 563a2c7dabb..4586fff1ba0 100644 --- a/peps/pep-0779.rst +++ b/peps/pep-0779.rst @@ -1,7 +1,7 @@ PEP: 779 Title: Criteria for supported status for free-threaded Python Author: Thomas Wouters , - Matt Page , + Matt Page , Sam Gross Status: Draft Type: Standards Track