
On 13 September 2017 at 20:45, Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Wed, Sep 13, 2017 at 6:14 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 13 September 2017 at 00:35, Koos Zevenhoven <k7hoven@gmail.com> wrote:>
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.)
"The interpreter that runs __main__" is never going to go away as a concept for the regular CPython CLI.
It's still just *an* interpreter that happens to run __main__. And who says it even needs to be the only one?
Koos, I've asked multiple times now for you to describe the practical user benefits you believe will come from dispensing with the existing notion of a main interpreter (which is *not* something PEP 554 has created - the main interpreter already exists at the implementation level, PEP 554 just makes that fact visible at the Python level). If you can't come up with a meaningful user benefit that would arise from removing it, then please just let the matter drop. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia