On Tue, 2020-04-28 at 19:20 -0600, Eric Snow wrote:
On Tue, Apr 21, 2020 at 11:17 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
Maybe one of the frustrating points about this criticism is that it does not belong in this PEP. And that is actually true! I wholeheartedly agree that it doesn't really belong in this PEP itself.
*But* the existence of a document detailing the "state and vision for subinterpreters" that includes these points is probably a prerequisite for this PEP. And this document must be linked prominently from the PEP.
So the suggestion should maybe not be to discuss it in the PEP, but to to write it either in the documentation on subinterpreters or as an informational PEP. Maybe such document already exists, but then it is not linked prominently enough probably.
That is an excellent point. It would definitely help to have more clarity about the feature (subinterpreters). I'll look into what makes the most sense. I've sure Victor has already effectively written something like this. :)
I will note one more time that I want to back up almost all that Nathaniel said (I simply cannot judge the technical side though). 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.) In many ways I assume that a lot of the ground work for subinterpreters was useful on its own. But please do not underestimate how much effort it will take to make subinterpreters first class citizen in the language! Take PyPy for example, it took years for PyPy support in NumPy (and the PyPy people did pretty much _all_ the work). And PyPy provides a compatibility layer that makes the support orders of magnitude simpler than supporting subinterpreters. And yet, I am sure there are many many C-Extensions out there that will fail on PyPy. So unless the potential subinterpreter userbase is magnitudes larger than PyPy's the situation will be much worse. With the added frustration because PyPy users probably expect incompatibilities, but Python users may get angry if they think subinterpreters are a language feature. There have been points made about e.g. just erroring on import for modules which do not choose to support subinterpreters. And maybe in the sum of saying: * We warn that most C-extensions won't work -> If you error, at least it won't crash silently (some mitigation) * Nobody must expect any C-extension to work until subinterpreters have proven useful *and* a large userbase! * In times, we are taking here about, what? - Maybe 3 years until proven useful and a potentially large userbase? - Some uncertain amount longer until the user-base actually grows - Maybe 5 years until fairly widespread support for some central libraries after that? (I am sure Python 2 to 3 took that long) * Prototyping the first few years (such as an external package, or even a fork!) are not really very good, because... ? Or alternatively the warnings will be so penetrant that prototyping within cpython is acceptable. Maybe you have to use: python --subinterpreters-i-know-this-is-only-a-potential-feature-which-may-be-removed-in-future-python-versions myscript.py This is not in the same position as most "experimental" APIs, which are almost settled but you want to be careful. This one has a real chance of getting ripped out entirely!? is good enough, maybe it is not. Once it is written down I am confident the Python devs and steering council will make the right call. Again, I do not want to hinder the effort. It takes courage and a good champion to go down such a long and windy road. But Nathaniel is right that putting in the effort puts you into the trap of thinking that now that we are 90% there from a Python perspective, we should go 100%. 100% is nice, but you may have to reach 1000++% (i.e. C-extension modules/ecysystem support) to actually have a fully functional feature. You should get the chance to prove them useful, there seems enough positivity around the idea. But the question is within what framework that can reasonably happen. Simply pushing in PEP 554 with a small warning in the documentation is not the right framework. I hope you can find the right framework to push this on. But unfortunately it is the difficult job of the features champion. And Nathaniel, etc. are actually trying to help you with it (but in the end are not champions for it, so you cannot expect too much). E.g. by asking if it cannot be developed outside of cpython and pointing out how other similar project approached the same impassible mountain of work. 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. - Sebastian PS: Sorry for the long post...
-eric _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2W2GOKCU... Code of Conduct: http://python.org/psf/codeofconduct/