<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 11 September 2017 at 00:52, Koos Zevenhoven <<a href="mailto:k7hoven@gmail.com">k7hoven@gmail.com</a>> wrote:<br>
> On Thu, Sep 7, 2017 at 9:26 PM, Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>><br>
> wrote:<br>
> [...]<br>
><br>
>><br>
>> get_main():<br>
>><br>
>>Â Â Return the main interpreter.<br>
>><br>
><br>
> I assume the concept of a main interpreter is inherited from the previous<br>
> levels of support in the C API, but what exactly is the significance of<br>
> being "the main interpreter"? Instead, could they just all be<br>
> subinterpreters of the same Python process (or whatever the right wording<br>
> would be)?<br>
<br>
</span>The main interpreter is ultimately responsible for the actual process<br>
global state: standard streams, signal handlers, dynamically linked<br>
libraries, __main__ module, etc.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​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?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The line between it and the "CPython Runtime" is fuzzy for both<br>
practical and historical reasons, but the regular Python CLI will<br>
always have a "first created, last destroyed" main interpreter, simply<br>
because we don't really gain anything significant from eliminating it<br>
as a concept.<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">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.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></div><span style="font-family:monospace,monospace">-- Koos</span></div><div class="gmail_quote"><font face="monospace, monospace"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​​</div></font></div><div class="gmail_quote"><font face="monospace, monospace"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​PS. There's a saying... something like "always say never" ;)</div></font></div><div class="gmail_quote"><font face="monospace, monospace"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div><br></font><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
By contrast, embedding applications that *don't* have a __main__<br>
module, and already manage most process global state themselves<br>
without the assistance of the CPython Runtime can already get pretty<br>
close to just having a pool of peer subinterpreters, and will<br>
presumably be able to get closer over time as the subinterpreter<br>
support becomes more robust.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan  |  <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>  |  Brisbane, Australia<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>