Concerns About Process With the Free-Threading Build and PEP 703

Core Development
1

Note: this thread is specifically about the core dev decision-making process, including the steering council. Please see one of the other threads I started for technical discussion.

Note: Bringing this up makes me uncomfortable, but no one else has and I think it’s important to discuss. Also, it’s hard to say any of this with the right tone and I don’t have the time to make it perfect. I definitely want this to be constructive, so please, please assume anything I say below is meant as positively as possible.

As the free-threading project has progressed I’ve become increasingly concerned about how the process has played out. Specifically:

  • pace
  • (undoubtedly unconscious) bias
  • a general vibe of an implicit mandate
  • pressure to make a (positive) decision about free-threading
  • alternatives not fairly considered (free-threading isn’t the only way to do parallelism)
  • no discussion (or apparent interest) about overlap between alternatives or between them and free-threading

Overall, I’m sensing a relatively pervasive sentiment that PEP 703 is inevitable and that it’s pointless to get in the way. That’s very atypical of how we usually operate. We’d be well-served by reflecting on if that’s how we want this to play out (and, of course, I could be wrong about all this).

Bias and Pressure

Note that I’m in a relatively unique position because of my efforts on solving multi-core parallelism using subinterpreters (which I’m convinced provides a valid alternative to free-threading). From here I’ve seen the following specific things happen:

  • the initial PEP 703 decision happened well ahead of schedule because of Meta funding pressure
  • pressure due to Meta funding (or at least the appearance of it) is ongoing
  • free-threading has a number of vocal cheerleaders (not a bad thing!), which contributes to social pressure (at the expense of technical considerations)
  • my initially expressed concerns about free-threading were never given any real attention (see here and here)
  • a year ago, PyUnstable_Module_SetGIL() was added without being part of PEP 703 (see discussion)
  • in 2018 the numpy project (NJS) responded to PEP 554 (subinterpreters) very negatively, while their response to free-threading has been quite positive, and I haven’t seen a strong basis for a difference, to me reflecting some underlying non-technical issue (or my own failure to communicate)
  • pytorch: didn’t really try with subinterpreters; why not? (I certainly never heard from anyone asking about how to do it)
  • my proposal for the language summit (2025) about alternatives to free-threading was rejected

Generally:

  • the GIL has received widespread, unwarranted disdain from the tech world for many years, contributing to social pressure
  • users tend to not have much understanding of how they will be impacted by free-threading, which contributes to social pressure
  • people tend to favor what’s familiar, and many are more familiar with threads than with the alternatives

All of the above represent various forms of pressure, bias, and priority that run counter to how we usually operate, not in a good way. There’s a pattern to how things have happened. However, to me the course of events mostly represents the determination of the people involved and a corresponding sense of purpose (and community mandate, whether warranted or not). [1]

I also want to be clear that things happening differently from normal does not make it bad. My main concern is that we make a decision about PEP 703 that serves the Python community best. That means having a clear picture of the real costs and benefits, including how widely the benefits apply relative to the costs.

That said, the way things have played out here feel off, and I do think we should avoid making a decision based on sunk costs, enterprise schedule, or wide-spread misinformation about the GIL, or without making sure the alternatives are insufficient.

  1. In the points that involve me, part of that is likely due to my own deficiencies in communication (but not exclusively) or my own misunderstanding or reading too much into things (admittedly I have an emotional stake in all this). ↩︎

14 Likes
2

My perception is that, if you understand multi-threading, it’s relatively easy to make a third-party project free-threading compatible, while making it subinterpreter-compatible seems more difficult while bringing more limited benefits. That is, you need specific knowledge about specific aspects of the Python C API and extension module initialization, rather than generic knowledge on the topic of multi-threading.

As I said in another discussion (for the record, we have a mixture of Cython and direct C API calls in PyArrow):

4 Likes
3

“If you understand multi-threading” is a pretty huge “if” though :wink: But overall I think you’ve read it correctly - subinterpreters are very CPython-specific, and so everyone else is starting from zero, whereas at least with preemptive multithreading the concept is roughly familiar already.

For better or worse, the process of “making it subinterpreter-compatible” has largely been required because Eric chose to block incompatible extensions, rather than letting them in to crash later. Which in theory ought to lead to someone reading the docs on how to become compatible and finding much of the same guidance as for free-threading (don’t use global C state, etc.), but it didn’t.

The apparent inevitability of free-threading probably caused some people to choose to invest their time there instead, and to write off subinterpreters without looking into them, but I don’t really know how big that was.

10 Likes
4

PyTorch tried to use subinterpreter approach several years ago.

5 Likes
5

And I would like to answer what we did at OH.

Threading would not be the best option we can provide. But the truth is we already provide threading with limited functionality and most of the new grad SWE are already familiar with the threading approach. It’s already an advantage itself for those reasons.

Subinterpreter OTAH has a good option if the user wants to sandboxed interpreters in the same process. I think that we can have two good options if we try

3 Likes
6

One quick clarification: I am not suggesting in any way that Meta funding for the PSF or anything else (other than the free-threading project itself) is tied to the decision about free-threading. I am sure that they are strictly separate.

2 Likes