Jul 16, 2024 · Jun 19, 2025 · Jun 20, 2025 · Jun 26, 2025 · Jun 30, 2025 · Jun 30, 2025
diff --git a/Doc/howto/multiple-interpreters.rst b/Doc/howto/multiple-interpreters.rst
   isolated from one another since there are few restrictions on memory
   access within the same process.  The Python runtime makes a best
   effort at isolation but extension modules may easily violate that.
   Therefore, do not use multiple interpreters in security-senstive
   Therefore, do not use multiple interpreters in security-sensitive
   situations, where they shouldn't have access to each other's data.

 That isolation facilitates a concurrency model basedan independent
 That isolation facilitates a concurrency model basedon independent
 logical threads of execution, like CSP or the actor model.

 Each actual thread in Python, even if you're only running in the main
  discipline about how the isolated components in your program interact
 * not all PyPI extension modules support multiple interpreters yet
 * the existing tools for passing data between interpreters safely
 is still relatively inefficient and limited
 are still relatively inefficient and limited
 * actually *sharing* data safely is tricky (true for free-threading too)
 * all necessary modules must be imported separately in each interpreter
 * relatively slow startup time per interpreter
 First of all, keep in mind that using multiple interpreters is like
 using multiple processes.  They are isolated and independent from each
 other.  The main difference is that multiple interpreters live in the
 same process, which makes it all more efficient anduse fewer
 same process, which makes it all more efficient anduses fewer
 system resources.

 Each interpreter has its own :mod:`!__main__` module, its own
 Mutable State is not Shared
 ---------------------------

 Justbe be clear, the underlying data of very few mutable objects is
 Justto be clear, the underlying data of very few mutable objects is
 actually shared between interpreters.  The notable exceptions are
 :class:`Queue` and :class:`memoryview`, which we will explore in a
 little while.  In nearly every case, the raw data is copied in
 to run the code.

 In the same way, running code in an interpreter does not reset that
 interpreter..  The next time you run code in that interpreter, the
 interpreter.  The next time you run code in that interpreter, the
 :mod:`!__main__` module will be in exactly the state in which you
 left it::

 the traceback and the process will exit with a failure code.

 The behavior is very similar when code is run in an interpreter.
 The tracebackget printed and, rather than a failure code,
 The tracebackgets printed and, rather than a failure code,
 an :class:`ExecutionFailed` exception is raised::

    from concurrent import interpreters
Original file line number	Diff line number	Diff line change
Expand Up		@@ -61,10 +61,10 @@ completely isolated from the others.
		isolated from one another since there are few restrictions on memory
		access within the same process. The Python runtime makes a best
		effort at isolation but extension modules may easily violate that.
		Therefore, do not use multiple interpreters in security-senstive
		Therefore, do not use multiple interpreters in security-sensitive
		situations, where they shouldn't have access to each other's data.

		That isolation facilitates a concurrency model basedan independent
		That isolation facilitates a concurrency model basedon independent
		logical threads of execution, like CSP or the actor model.

		Each actual thread in Python, even if you're only running in the main
Expand All		@@ -86,7 +86,7 @@ There are some downsides and temporary limitations:
		discipline about how the isolated components in your program interact
		* not all PyPI extension modules support multiple interpreters yet
		* the existing tools for passing data between interpreters safely
		is still relatively inefficient and limited
		are still relatively inefficient and limited
		* actually sharing data safely is tricky (true for free-threading too)
		* all necessary modules must be imported separately in each interpreter
		* relatively slow startup time per interpreter
Copy link Contributor neoneneJul 2, 2025 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. Some users might need a (foot)note that subinterpreters can sometimes improve the startup by importing nothing. example defnon_stateless():non_statelessif__name__=='__main__':importthreadingfromconcurrentimportinterpretersinterps= [interpreters.create()foriinrange(10)]threads= [threading.Thread(target=interp.call,args=(non_stateless,))forinterpininterps ]forthreadinthreads:thread.start()forthreadinthreads:thread.join() That seems not so beneficial for the`InterpreterPoolExecutor` case, though. Copy link MemberAuthor ericsnowcurrentlyJul 3, 2025 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. I've added a note, though further down in the discussion about calling functions. neonene reacted with heart emoji
Expand All		@@ -103,7 +103,7 @@ Tutorial: Basics
		First of all, keep in mind that using multiple interpreters is like
		using multiple processes. They are isolated and independent from each
		other. The main difference is that multiple interpreters live in the
		same process, which makes it all more efficient anduse fewer
		same process, which makes it all more efficient anduses fewer
		system resources.

		Each interpreter has its own :mod:`!__main__` module, its own
Expand DownExpand Up		@@ -375,7 +375,7 @@ the same rules as functions::
		Mutable State is not Shared
		---------------------------

		Justbe be clear, the underlying data of very few mutable objects is
		Justto be clear, the underlying data of very few mutable objects is
		actually shared between interpreters. The notable exceptions are
		:class:`Queue` and :class:`memoryview`, which we will explore in a
		little while. In nearly every case, the raw data is copied in
Expand DownExpand Up		@@ -428,7 +428,7 @@ the builtin :func:`exec`, it doesn't reset the namespace it uses
		to run the code.

		In the same way, running code in an interpreter does not reset that
		interpreter.. The next time you run code in that interpreter, the
		interpreter. The next time you run code in that interpreter, the
		:mod:`!__main__` module will be in exactly the state in which you
		left it::

Expand DownExpand Up		@@ -535,7 +535,7 @@ and there's an unhandled exception. In that case, Python will print
		the traceback and the process will exit with a failure code.

		The behavior is very similar when code is run in an interpreter.
		The tracebackget printed and, rather than a failure code,
		The tracebackgets printed and, rather than a failure code,
		an :class:`ExecutionFailed` exception is raised::

		from concurrent import interpreters
Expand Down