Skip to content

Commit 22e3ee0

Browse files
Clarify about calling different kinds of function.
1 parent 675246d commit 22e3ee0

File tree

1 file changed

+76
-24
lines changed

1 file changed

+76
-24
lines changed

Doc/howto/multiple-interpreters.rst

Lines changed: 76 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -242,7 +242,7 @@ highlighting in your editor. With script text you probably don't.
242242
Calling a Function in an Interpreter
243243
------------------------------------
244244

245-
You can just as easily call a function in another interpreter::
245+
You can just as easily *call* a function in another interpreter::
246246

247247
from concurrent import interpreters
248248

@@ -254,13 +254,30 @@ You can just as easily call a function in another interpreter::
254254
interp.call(spam)
255255
# prints: spam!
256256

257-
In fact, nearly all Python functions and callables are supported,
258-
with the notable exception of closures. Support includes arguments
259-
and return values, which we'll
260-
:ref:`explore soon <interp-tutorial-return-values>`.
257+
(See :meth:`Interpreter.call`.)
261258

262-
Builtin functions always execute in the target interpreter's
263-
:mod:`!__main__` module::
259+
In fact, nearly all Python functions and callables are supported, with
260+
the notable exclusion of closures. We'll focus on plain functions
261+
for the moment.
262+
263+
Relative to :meth:`Interpreter.call`, there are five kinds of functions:
264+
265+
1. builtin functions
266+
2. extension module functions
267+
3. "stateless" user functions
268+
4. stateful user functions, defined in :mod:`!__main__`
269+
5. stateful user functions, not defined in :mod:`!__main__`
270+
271+
A "stateless" function is one that doesn't use any globals. It also
272+
can't be a closure. It can have parameters but not argument defaults.
273+
It can have return values. We'll cover
274+
:ref:`arguments and returning <interp-tutorial-return-values>` soon.
275+
276+
Some builtin functions, like :func:`exec` and :func:`eval`, use the
277+
current globals as a default (or :func:`implicit <globals>`) argument
278+
value. When such functions are called directly with
279+
:meth:`Interpreter.call`, they use the :mod:`!__main__` module's
280+
:data:`!__dict__` as the default/implicit "globals"::
264281

265282
from concurrent import interpreters
266283

@@ -272,23 +289,29 @@ Builtin functions always execute in the target interpreter's
272289
interp.call(eval, 'print(__name__)')
273290
# prints: __main__
274291

275-
The same is true for Python functions that don't use any globals::
292+
Note that, for some of those builtin functions, like :func:`globals`
293+
and even :func:`eval` (for some expressions), the return value may
294+
be :ref:`"unshareable" <interp-tutorial-shareable>` and the call will
295+
fail.
276296

277-
from concurrent import interpreters
297+
In each of the above cases, the function is more-or-less copied, when
298+
sent to the other interpreter. For most of the cases, the function's
299+
module is imported in the target interpreter and the function is pulled
300+
from there. The exceptions are cases (3) and (4).
278301

279-
def spam():
280-
# globals is a builtin.
281-
print(globals()['__name__'])
282-
283-
if __name__ == '__main__':
284-
interp = interpreters.create()
285-
interp.call(spam)
286-
# prints: __main__
302+
In case (3), the function is also copied, but efficiently and only
303+
temporarily (long enough to be called) and is not actually bound to
304+
any module. This temporary function object's :data:`!__name__` will
305+
be set to match the code object, but the :data:`!__module__`,
306+
:data:`!__qualname__`, and other attributes are not guaranteed to
307+
be set. This shouldn't be a problem in practice, though, since
308+
introspecting the currently running function is fairly rare.
287309

288-
There are very few cases where that matters, though.
310+
We'll cover case (4) in
311+
:ref:`the next section <interp-tutorial-funcs-in-main>`.
289312

290-
Otherwise, functions defined in modules other than :mod:`!__main__` run
291-
in that module::
313+
In all the cases, the function will get any global variables from the
314+
module (in the target interpreter), like normal::
292315

293316
from concurrent import interpreters
294317
from mymod import spam
@@ -305,9 +328,25 @@ in that module::
305328
def spam():
306329
print(__name__)
307330

308-
For a function actually defined in the :mod:`!__main__` module,
309-
it executes in a separate dummy module, in order to not pollute
310-
the :mod:`!__main__` module::
331+
Note, however, that in case (3) functions rarely look up any globals.
332+
333+
.. _interp-tutorial-funcs-in-main:
334+
335+
Functions Defined in __main__
336+
-----------------------------
337+
338+
Functions defined in :mod:`!__main__` are treated specially by
339+
:meth:`Interpreter.call`. This is because the script or module that
340+
ran in the main interpreter will have not run in other interpreters,
341+
so any functions defined in the script would only be accessible by
342+
running it in the target interpreter first. That is essentially
343+
how :meth:`Interpreter.call` handles it.
344+
345+
If the function isn't found in the target interpreter's :mod:`!__main__`
346+
module then the script that ran in the main interpreter gets run in the
347+
target interpreter, though under a different name than "__main__".
348+
The function is then looked up on that resulting fake __main__ module.
349+
For example::
311350

312351
from concurrent import interpreters
313352

@@ -319,7 +358,12 @@ the :mod:`!__main__` module::
319358
interp.call(spam)
320359
# prints: '<fake __main__>'
321360

322-
This means global state used in such a function won't be reflected
361+
The dummy module is never added to :data:`sys.modules`, though it may
362+
be cached away internally.
363+
364+
This approach with a fake :mod:`!__main__` module means we can avoid
365+
polluting the :mod:`!__main__` module of the target interpreter. It
366+
also means global state used in such a function won't be reflected
323367
in the interpreter's :mod:`!__main__` module::
324368

325369
from textwrap import dedent
@@ -369,6 +413,12 @@ in the interpreter's :mod:`!__main__` module::
369413
print(total)
370414
# prints: 0
371415

416+
Note that the recommended ``if __name__ == '__main__`:`` idiom is
417+
especially important for such functions, since the script will be
418+
executed with :data:`!__name__` set to something other than
419+
:mod:`!__main__`. Thus, for any code you don't want run repeatedly,
420+
put it in the if block. You will probably only want functions or
421+
classes outside the if block.
372422

373423
Calling Methods and Other Objects in an Interpreter
374424
---------------------------------------------------
@@ -810,6 +860,8 @@ For example::
810860
assert res is not data
811861
assert data == dict(a=1, b=2, c=3)
812862

863+
.. _interp-tutorial-shareable:
864+
813865
Supported and Unsupported Objects
814866
---------------------------------
815867

0 commit comments

Comments
 (0)