On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 11 September 2017 at 00:52, Koos Zevenhoven <k7hoven@gmail.com> wrote:
> On Thu, Sep 7, 2017 at 9:26 PM, Eric Snow <ericsnowcurrently@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@gmail.com   |   Brisbane, Australia



--
+ Koos Zevenhoven + http://twitter.com/k7hoven +