Thanks for the thoughtful post! I'm going to address some of your comments here and some in a separate discussion in the next few days. On Wed, Apr 29, 2020 at 10:36 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
While I still think it is probably not part of PEP 554 as such, I guess it needs a full blown PEP on its own. Saying that Python should implement subinterpreters. (I am saying "implement" because I believe you must consider subinterpreters basically a non-feature at this time. It has neither users nor reasonable ecosystem support.)
FWIW, at this point it would be hard to justify removing the existing public subinterpreters C-API. There are several large public projects using it and likely many more private ones we do not know about. That's not to say that alone justifies exposing the C-API, of course. :)
In many ways I assume that a lot of the ground work for subinterpreters was useful on its own.
There has definitely been a lot of code health effort related to the CPython runtime code, partly motivated by this project. :)
But please do not underestimate how much effort it will take to make subinterpreters first class citizen in the language!
If you are talking about on the CPython side, most of the work is already done. The implementation of PEP 554 is nearly complete and subinterpreter support in the runtime has a few rough edges to buff out. The big question is the effort it will demand of the Python community, which is the point Nathaniel has been emphasizing (understandably).
Believe me, I have been there and its tough to write these documents and then get feedback which you are not immediately sure what to make of. Thus, I hope those supporting the idea of subinterpreters will help you out and formulate a better framework and clarify PEP 554 when it comes to the fuzzy long term user-impact side of the PEP.
FYI, I started working on this project in 2015 and proposed PEP 554 in 2017. This is actually the 6th round of discussion since then. :) -eric