Eric V. Smith wrote:
Hi Petr, On 09/06/2020 2:24 pm, Petr Viktorin wrote: On 2020-06-05 16:32, Mark Shannon wrote: Whether Python interpreters run sequentially or in parallel, having them work will enable a use case I would like to see: allowing me to call Python code from wherever I want, without thinking about global state. Think calling Python from an utility library that doesn't care about the rest of the application it's used in. I personally call this "the Lua use case", because light-weight, worry-free embedding is an area where Python loses to Lua. (And JS as well—that's a relatively recent development, but much more worrying.) This seems like a worthwhile goal. However I don't see why this requires having multiple Python interpreters in a single O/S process. I assume it would be so that my code could link with library A, which embeds Python, and library B, which also embeds Python. A and B have no knowledge of each other. The part I have been involved in is moving away from process-global state. Process-global state can be made to work, but it is much safer to always default to module-local state (roughly what Python-language's global means), and treat process-global state as exceptions one has to think through. The API introduced in PEPs 384, 489, 573 (and future planned ones) aims to make module-local state possible to use, then later easy to use, and the natural default. I don't agree. Process level state is much safer than module-local state. Suppose two interpreters, have both imported the same module. By using O/S processes to keep the interpreters separate, the hardware prevents the two copies of the module from interfering with each other. By sharing an address space the separation is maintained by trust and hoping that third party modules don't have too many bugs. I don't see how you can claim the later case if safer. I've always assumed that per-module state meant per-module,
On 6/10/2020 8:33 AM, Mark Shannon wrote: per-interpreter.
It _can_, but it isn't guaranteed because we are talking about C here and people do "interesting" things when they are handed that much flexibility. 😉 Plus a bunch of work has been done in the last few years to make per-interpreter state for modules be supported. -Brett
Maybe I've misunderstood, in which case I agree with Mark. If per-module state isn't isolated per interpreter, that sort of kills the multiple interpreter model, in my mind. Eric