<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Tue, Sep 12, 2017 at 1:40 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11 September 2017 at 18:02, Koos Zevenhoven <<a href="mailto:k7hoven@gmail.com">k7hoven@gmail.com</a>> wrote:<br>
> On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
</span><span class="">>> 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>
><br>
> I fear that emphasizing the main interpreter will lead to all kinds of<br>
> libraries/programs that somehow unnecessarily rely on some or all tasks<br>
> being performed in the main interpreter. Then you'll have a hard time<br>
> running two of them in parallel in the same process, because you don't have<br>
> two main interpreters.<br>
<br>
</span>You don't need to fear this scenario, since it's a description of the<br>
status quo (and it's the primary source of overstated claims about<br>
subinterpreters being "fundamentally broken").<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Well, if that's true, it's hardly a counter-argument to what I said. Anyway, there is no status quo about what is proposed in the PEP.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">And as long as the existing APIs are preserved, why not make the new one less susceptible to overstated fundamental brokenness?</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So no, not everything will be subinterpreter-friendly, just as not<br>
everything in Python is thread-safe, and not everything is portable<br>
across platforms. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">I don't see how the situation benefits from calling something the "main interpreter".​ Subinterpreters can be a way to take something non-thread-safe and make it thread-safe, because in an interpreter-per-thread scheme, most of the state, like module globals, are thread-local. (Well, this doesn't help for async concurrency, but anyway.)</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's OK - it just means we'll aim to make as many<br>
things as possible implicitly subinterpreter-friendly, and for<br>
everything else, we'll aim to minimise the adjustments needed to<br>
*make* things subinterpreter friendly.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​And that's exactly what I'm after here! </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I'm mostly just worried about the `get_main()` function. Maybe it should be called `asdfjaosjnoijb()`, so people wouldn't use it. Can't the first running interpreter just introduce itself to its children? And if that's too much to ask, maybe there could be a `get_parent()` function, which would give you the interpreter that spawned the current subinterpreter. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Well OK, perhaps the current implementation only allows the "main interpreter" to spawn new interpreters (I have no idea). In that case, `get_parent()` will just be another, more future-proof name for `get_main()`. Then it would just need a clear documentation of the differences between the parent and its children. If the author of user code is not being too lazy, they might even read the docs and figure out if they *really* need to make a big deal out of which interpreter is the main/parent one.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Still, I'm not convinced that there needs to be a get_main or get_parent. It shouldn't be too hard for users to make a wrapper around the API that provides this functionality. And if they do that––and use it to make their code "fundamentally broken"––then... at least we tried.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">––Koos</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>