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?

Right now, its also a restriction even for applications like mod_wsgi,
since the GIL state APIs always register C created threads with the
main interpreter.

>> That's OK - it just means we'll aim to make as many
>> things as possible implicitly subinterpreter-friendly, and for
>> everything else, we'll aim to minimise the adjustments needed to
>> *make* things subinterpreter friendly.
>>
>
> And that's exactly what I'm after here!

No, you're after deliberately making the proposed API
non-representative of how the reference implementation actually works
because of a personal aesthetic preference rather than asking yourself
what the practical benefit of hiding the existence of the main
interpreter would be.

The fact is that the main interpreter *is* special (just as the main
thread is special), and your wishing that things were otherwise won't
magically make it so.

​I'm not questioning whether the main interpreter is special, or whether the interpreters may differ from each other. I'm questioning the whole concept of "main interpreter". People should not care about which interpreter is "the main ONE". They should care about what properties an interpreter has. That's not aesthetics. Just look at, e.g. the _decimal/_pydecimal examples in this thread.

> 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.

If the embedding application never calls
"_Py_ConfigureMainInterpreter", then get_main() could conceivably
return None. However, we don't expose that as a public API yet, so for
the time being, Py_Initialize() will always call it, and hence there
will always be a main interpreter (even in things like mod_wsgi).

You don't need to remove _Py_ConfigureMainInterpreter. Just make sure you don't try to smuggle it into the status quo of the possibly upcoming new stdlib module. Who knows what the function does anyway, let alone what it might or might not do in the future. 

Of course that doesn't mean that there couldn't be ways to configure an interpreter, but coupling that with a concept of a "main interpreter", as you suggest, doesn't seem to make any sense. And surely the code that creates a new interpreter should know if it wants the new interpreter to start with `__name__ == "__main__"` or `__name__ == "__just_any__", if there is a choice.

––Koos

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