It’s not clear to me to what extent the SC is in a position to tie PEP acceptance or rejection to allocation of funding. I think it would be helpful if @markshannon or @guido can shed more light on what you mean by “additional funding”.
If we end up taking the free-threading-multi-core route, what kind of additional funding will be required, in what form, and for what goal?
If “additional funding” can manifest in the form of “allocating PSF-employed and SC-directed CPython developer(s)” then that’s probably something the SC can decide to do (but maybe not a consideration in PEP acceptance or rejection?).
If “additional funding” towards “option 3” must take the form of “the Faster CPython team hires N more world-class cpython devs” (on top of the existing world-class core devs already on that team), then I don’t know how the SC can do anything about it, nor how they can take that into consideration when making their decision.
It is also important to have more clarity on the implications of “lack of additional funding”.
Let’s do a thought experiment where the SC decided to accept PEP-703, and there is no additional funding.
My assumption is that the 5x single-threaded speedup will not be achieved in the timeframe of the original plan (was a specific timeline set? is it “by 3.15”?).
What happens next? If the existing funding for the Faster CPython team dries up as a result (e.g. because the original goal can no longer be achieved “on time”), that’s a pretty bad outcome, but also a very different one from “the existing funding stays as is and it takes N more releases to achieve the 5x goal” (or even “it takes N more releases and we end up with “only” 3x”).
Python had existed for a long time now, and I expect it will continue to exist for many more decades.
I share @gpshead 's sentiment:
In my opinion, “declaring a performance dead end” can be a defensible position. It is a valid strategy to avoid multi-core-free-threading complexity and continue investing in single core performance up to that dead end, and plenty of use-cases out there are very well served with “the best single-core language in the world”.
But it must be a decision made explicitly and intentionally!
If this is made explicit, then it will be clear to the community that there’s no point in trying to “solve” the multi-core-free-threading problem (at any expense to single-core performance), and future @colesbury es will not need to invest years in trying to tackle it.
But if, on the other hand, there’s an expectation (consensus?) that “we would have to deal with multi-core eventually”, then it becomes a question of when, how, and who.
PEP-703 is one option (arguably, the best option proposed so far). PEP-684 (per-interpreter-GIL) is another (not mutually exclusive to PEP-703 according to @eric.snow ) option. There may be more options in the future.
I think what’s missing is a “meta-decision” about the long-term strategy:
- We want to have a good multi-core story; vs
- We declare Python as the best single-core language
If the meta-decision is “we want a good multi-core story”, then I think something that @colesbury has been asking for is “what does an acceptable good multi-core story look like”, because without a framework to operate in, all we have to guide us is an invisible moving goalpost.