# PEP 779: Criteria for supported status for free-threaded Python **URL:** \ **Category:** PEPs\ **Created:** [March 13, 2025, 12:25pm UTC](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319 "2025-03-13T12:25:19Z")\ **Posts on this page:** 4\ **Page:** 8
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [June 26, 2025, 6:22pm UTC](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319/141 "2025-06-26T18:22:50Z")
> [@corona10](#): > > The Steering Council also expects that Stable ABI for free-threading should be prepared and defined for Python 3.15. Over at [Stable ABI/Limited API for free-threaded builds](https://discuss.python.org/t/stable-abi-limited-api-for-free-threaded-builds/86458) we’ve been debating this - should we assume that the wording here is intended to imply that “Stable ABI for free-threading” is distinct from “Stable ABI for non-free-threading”? Or is the possibility of one (new) Stable ABI that covers both free-threading and non-free-threading allowed? (See the discussion I linked, but in short, there is more than one reason we think it’s worth “resetting” the stable ABI, and free-threading needs are just a forcing function.) ---
**Author:** ![corona10](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/corona10/32/9943_2.png) [@corona10](https://discuss.python.org/u/corona10)\ **Post date:** [June 26, 2025, 6:33pm UTC](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319/142 "2025-06-26T18:33:05Z")
> [@steve.dower](#): > > Over at [Stable ABI/Limited API for free-threaded builds](https://discuss.python.org/t/stable-abi-limited-api-for-free-threaded-builds/86458) we’ve been debating this - should we assume that the wording here is intended to imply that “Stable ABI for free-threading” is distinct from “Stable ABI for non-free-threading”? Or is the possibility of one (new) Stable ABI that covers both free-threading and non-free-threading allowed? (See the discussion I linked, but in short, there is more than one reason we think it’s worth “resetting” the stable ABI, and free-threading needs are just a forcing function.) SC is aware that there are two possible approaches and is currently considering which path would be more reasonable and practical. While no final decision has been made yet, I believe this should be decided through further discussion(including the C API working group) and careful evaluation. ---
**Author:** ![dimaqq](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dimaqq/32/372_2.png) [@dimaqq](https://discuss.python.org/u/dimaqq)\ **Post date:** [June 13, 2026, 2:00pm UTC](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319/143 "2026-06-13T14:00:08Z")
Do we need to update PEP 709? Today, PEP 709 states that the default will be flipped 2028~2030, while this PEP states that specific performance, etc. targets must be met before the flip. ---
**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\ **Post date:** [June 13, 2026, 9:22pm UTC](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319/144 "2026-06-13T21:22:33Z")
Assuming you meant [PEP 703 – Making the Global Interpreter Lock Optional in CPython ](https://peps.python.org/pep-0703/) and not [PEP 709 – Inlined comprehensions](https://peps.python.org/pep-0709/) 🙂 No, 703 doesn’t need updating because: - the year-based flip is just a suggestion: “The path to this goal remains an open issue, but a possible path might look like the following: […] After another 2–3 release (i.e., 2028–2030), CPython switches to the GIL being disabled by default.” - There will be another PEP, similar to 779, to define the criteria for any such future change. - Standards track PEPs are historical documents and aren’t usually updated. But yes, it does need updating because: - the status should be updated from Active to Final (this will happen in [python/peps#4986](https://github.com/python/peps/pull/4986)). [Previous page](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319.md?page=7)