PEP 779: Criteria for supported status for free-threaded Python

Thanks for the PEP! I appreciate the effort to set clearer expectations surrounding next steps.

Assuming you’re able to share, are there any specific learnings or experiences after joining the team that led to such a dramatic shift?

This comment just caught my attention, since you had already thought quite long and hard about this issue as an SC member (and fellow core dev). I myself fall into the “reasonably-skeptical-of-the-tradeoffs-but-it-feels-inevitable-so-I’ll-just-deal-with-it” camp, and would honestly love the peace-of-mind from being convinced that it will “absolutely work out” for us as CPython maintainers. :slight_smile:

The lottery doesn’t worry me much. I’m personally a bit more concerned that most (not all) of the current free-threading work and maintenance in the CPython core is, to my knowledge, thanks to Meta’s pledge to commit three engineer years through the end of 2025. That post notes that in addition to landing PEP 703, this includes “ongoing improvements to the compatibility and performance of nogil CPython”… which I guess means a similar level of involvement that we saw from Meta engineers pre-PEP-703, but now with an emphasis on free-threading.

I know these people, and I don’t doubt their personal commitment to CPython’s success one bit. But they’re working full-time on maintaining the free-threading build right now, and I think we as a project should make sure that we can handle the ongoing burden once they’re no longer able to do this ~120 hours a week, especially once people start “demanding” that we keep it working. It might even make sense for the PEP to address this explicitly.

10 Likes