PEP 734 has been a tough one.
First, let me state unequivocally that I personally greatly appreciate Eric’s years-long dedication, tenacity, drive, and technical excellence on the subinterpreters feature. Regardless of whether the subinterpreters feature is popular among Python developers, I think the work that has gone into CPython to support them has benefited Python in many ways. The insights Eric has gained by working on subinterpreters (e.g. PEP 683’s immortal objects) has also contributed valuable expertise to other “big initiatives” going on in Python.
Subinterpreters also provides an alternative option for Python users who want to utilize more of the processing power of their computers. E.g. with PEP 684’s per-interpreter GIL, the “global” interpreter lock is a little less global, and thus opens up more use cases for parallelism (some might even say concurrency 
).
All that being said, both the 2024 and 2025 SC’s have struggled with PEP 734 in at least two related ways. With apologies to Eric if I am misrepresenting his viewpoint:
- Is the API proposed in the PEP the “right” one? API design is difficult and as we all know, once a module is added to the stdlib, it becomes much harder to change and evolve. We’ve tried to address that with “provisional” APIs, but that experiment has been failure, IMHO[1]. We can’t semver stdlib modules, and so a strong recommendation these days is that a module should be released on PyPI, evolve there for a while, and only once its API has settled down and been proven on real-world use cases, should it be considered for the stdlib. PEP 2 needs a serious update.
- Is the subinterpreters feature popular enough to “graduate” into the stdlib and claim a top-level stdlib name? Eric has argued that the Python module is so closely tied to the underlying interpreter feature, and useful enough in its own right aside from the utility of the subinterpreters feature, that it does deserve to be in the stdlib and that putting it at the top level gives it the visibility required to make the feature more discoverable, and thus more popular[2].
With these questions in mind, the previous SC recommended a PyPI release of the subinterpreters module to try to answer these two questions: is the API right and is the feature useful enough? Eric did release to PyPI but ISTM rather unenthusiastically, given the hard to find name and the admonition at the top of the PyPI index page. Sadly, I don’t think this PyPI-first experiment really helped answer or clarify either question.
+1 to both of Greg’s statements. I think both 2024’s and 2025’s SC would have been perfectly comfortable rejecting PEP 734 and recommending just having a PyPI module for the, IMHO limited number of actual users of the Python level API. If the “normal”[3] policy for module inclusion into the stdlib had been followed, maybe after a while it would have made sense to add, but as of right now, I remain unconvinced. I’m also unconvinced that adding it to the stdlib will make the subinterpreters feature itself more popular, given all the other ways to do concurrent[4] programming in Python.
And yet, Eric certainly has brought the same tenacity to the PEP 734 discussion as he has to the subinterpreters feature. We’ve had countless discussions in public and private, in SC office hours, at conferences and summits, etc. about 734. I think it’s that tenacity that staved off our strong inclination to reject 734. Small victories, hard won.
As an aside, the documentation is quite good. You should go read it! Maybe it will inspire you to find other interesting use cases for subinterpreters.
Ultimately, it’s just a name, and I still don’t think that the name of the Python module will make any difference in the adoption of the feature. I hope I’m proven wrong, and if the users of it come back to some future SC and make a good argument for why it needs to be renamed, it’s pretty easy to do so, although it might take longer to deprecate the old name. It’s not like that hasn’t been done before though.
And I don’t think concurrent is inherently wrong. IMHO, there’s no perfect place for it within the stdlib, including at the top-level, and at least you can argue that a common use case for multiple interpreters is to boost concurrency. Despite the ability to use them in single threaded programs, I’ve yet to hear of an actual use case for that.
On the process question: as I’ve said before, I commend Eric for speaking his mind about the decision making process, and the SC’s role in Python’s technical evolution. As Tim asks above, I definitely acknowledge Eric’s frustration with the process, but I disagree that the SC hasn’t tried to reach consensus on the issue.
As with so much of Python over its 30+ years, we’re making it up as we go along, and I can proudly say that in the majority of cases, decisions are made with thoughtful deliberation[5], with Python’s best interests in mind, and with compassion and gratitude to all the folks who contribute to it. Human endeavors are messy, we all make mistakes, and we all have our implicit[6] biases. We must be self-reflective and never be afraid to question whether we need a course adjustment, but we also need to “commit and move forward” otherwise we’ll just thrash, and that is also unhealthy to our community.
Elsewhere related to process, I pointed out how to get a topic on the SC’s agenda.
