Sure, but this question and PEP goes directly to the open issue in PEP 779 – Criteria for supported status for free-threaded Python | peps.python.org, which was directed by the SC to be discussed for 3.15, but no specific design was mandated. That’s what we’re doing here (and Petr and I have largely been doing spread over a number of locations since before PEP 779 was accepted).
My primary concern with any of the proposals so far[1] is dividing the community for an unspecified length of time.[2] The choices largely come down to one of:
abi3is broken at an arbitrarily timeabi3texists until free-threading becomes default and thenabi3no longer existsabi3andabi4exist in parallel, the latter supported by both builds, andabi3no longer exists once free-threading becomes the default- free-threading has no stable ABI until it becomes the default (status quo, but already rejected by the SC)
I don’t particularly have specific desires about the contents of the new ABI[3] - virtually everything I’ve seen proposed has been pretty uncontroversial IMHO - it’s just that some of it is necessarily breaking the ABI and I think option 3 above manages that better than options 1 or 2.
I haven’t had time to work up more than a sketch of a proposal, but my core criteria follows. ↩︎
I originally wrote “permanently” knowing that’s not true, but it definitely flows better to use a touch of hyperbole and say that my primary concern is permanently dividing the community. ↩︎
I have some ideas about future longevity, so we aren’t changing it every release like we have been with
abi3, but those are totally separate from the free-threading issue, e.g. they could also be added toabi3safely. ↩︎