On Tue, 2020-04-28 at 19:20 -0600, Eric Snow wrote:
> On Tue, Apr 21, 2020 at 11:17 AM Sebastian Berg
> <sebast...@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-le...@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/2W2GOKCUV35BAOX75ILD7XOIGWCXJ5KN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/BESGJI4RGTJONXUF75PBTSQBA6PKU6M4/
Code of Conduct: http://python.org/psf/codeofconduct/
