Eric V. Smith wrote: > On 6/10/2020 8:33 AM, Mark Shannon 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, > 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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WEVPITVEFX72ONIEOJ5VQZSGOCPSRLSQ/ Code of Conduct: http://python.org/psf/codeofconduct/
