Over at Stable ABI/Limited API for free-threaded builds 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.)
3 Likes
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.
2 Likes
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.
Assuming you meant PEP 703 – Making the Global Interpreter Lock Optional in CPython
and not PEP 709 – Inlined comprehensions 
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).
3 Likes