[Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

[Koos Zevenhoven]

On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 11 September 2017 at 00:52, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> > On Thu, Sep 7, 2017 at 9:26 PM, Eric Snow <ericsnowcurrently at gmail.com>
> > wrote:
> > [...]
> >
> >>
> >> get_main():
> >>
> >>    Return the main interpreter.
> >>
> >
> > I assume the concept of a main interpreter is inherited from the previous
> > levels of support in the C API, but what exactly is the significance of
> > being "the main interpreter"? Instead, could they just all be
> > subinterpreters of the same Python process (or whatever the right wording
> > would be)?
>
> The main interpreter is ultimately responsible for the actual process
> global state: standard streams, signal handlers, dynamically linked
> libraries, __main__ module, etc.
>
>
​Hmm. It is not clear, for instance, why a signal handler could not be
owned by an interpreter that wasn't the first one started.​ Or, if a
non-main process imports a module from a dynamically linked library, does
it delegate that to the main interpreter? And do sys.stdout et al. not
exist in the other interpreters?

The line between it and the "CPython Runtime" is fuzzy for both
> practical and historical reasons, but the regular Python CLI will
> always have a "first created, last destroyed" main interpreter, simply
> because we don't really gain anything significant from eliminating it
> as a concept.
>

I fear that emphasizing the main interpreter will lead to all kinds of
libraries/programs that somehow unnecessarily rely on some or all tasks
being performed in the main interpreter. Then you'll have a hard time
running two of them in parallel in the same process, because you don't have
two main interpreters.

-- Koos
​​
​PS. There's a saying... something like "always say never" ;)
​

​


> By contrast, embedding applications that *don't* have a __main__
> module, and already manage most process global state themselves
> without the assistance of the CPython Runtime can already get pretty
> close to just having a pool of peer subinterpreters, and will
> presumably be able to get closer over time as the subinterpreter
> support becomes more robust.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>



-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170911/a9204d43/attachment.html>