31.7. "runpy" — Locating and executing Python modules
*****************************************************

Novo na versão 2.5.

**Source code:** Lib/runpy.py

======================================================================

The "runpy" module is used to locate and run Python modules without
importing them first. Its main use is to implement the "-m" command
line switch that allows scripts to be located using the Python module
namespace rather than the filesystem.

The "runpy" module provides two functions:

runpy.run_module(mod_name, init_globals=None, run_name=None, alter_sys=False)

   Execute the code of the specified module and return the resulting
   module globals dictionary. The module’s code is first located using
   the standard import mechanism (refer to **PEP 302** for details)
   and then executed in a fresh module namespace.

   If the supplied module name refers to a package rather than a
   normal module, then that package is imported and the "__main__"
   submodule within that package is then executed and the resulting
   module globals dictionary returned.

   The optional dictionary argument *init_globals* may be used to pre-
   populate the module’s globals dictionary before the code is
   executed. The supplied dictionary will not be modified. If any of
   the special global variables below are defined in the supplied
   dictionary, those definitions are overridden by "run_module()".

   The special global variables "__name__", "__file__", "__loader__"
   and "__package__" are set in the globals dictionary before the
   module code is executed (Note that this is a minimal set of
   variables - other variables may be set implicitly as an interpreter
   implementation detail).

   "__name__" is set to *run_name* if this optional argument is not
   "None", to "mod_name + '.__main__'" if the named module is a
   package and to the *mod_name* argument otherwise.

   "__file__" is set to the name provided by the module loader. If the
   loader does not make filename information available, this variable
   is set to "None".

   "__loader__" is set to the **PEP 302** module loader used to
   retrieve the code for the module (This loader may be a wrapper
   around the standard import mechanism).

   "__package__" is set to *mod_name* if the named module is a package
   and to "mod_name.rpartition('.')[0]" otherwise.

   If the argument *alter_sys* is supplied and evaluates to "True",
   then "sys.argv[0]" is updated with the value of "__file__" and
   "sys.modules[__name__]" is updated with a temporary module object
   for the module being executed. Both "sys.argv[0]" and
   "sys.modules[__name__]" are restored to their original values
   before the function returns.

   Note that this manipulation of "sys" is not thread-safe. Other
   threads may see the partially initialised module, as well as the
   altered list of arguments. It is recommended that the "sys" module
   be left alone when invoking this function from threaded code.

   Ver também: The "-m" option offering equivalent functionality
     from the command line.

   Alterado na versão 2.7: Added ability to execute packages by
   looking for a "__main__" submodule

runpy.run_path(file_path, init_globals=None, run_name=None)

   Execute the code at the named filesystem location and return the
   resulting module globals dictionary. As with a script name supplied
   to the CPython command line, the supplied path may refer to a
   Python source file, a compiled bytecode file or a valid sys.path
   entry containing a "__main__" module (e.g. a zipfile containing a
   top-level "__main__.py" file).

   For a simple script, the specified code is simply executed in a
   fresh module namespace. For a valid sys.path entry (typically a
   zipfile or directory), the entry is first added to the beginning of
   "sys.path". The function then looks for and executes a "__main__"
   module using the updated path. Note that there is no special
   protection against invoking an existing "__main__" entry located
   elsewhere on "sys.path" if there is no such module at the specified
   location.

   The optional dictionary argument *init_globals* may be used to pre-
   populate the module’s globals dictionary before the code is
   executed. The supplied dictionary will not be modified. If any of
   the special global variables below are defined in the supplied
   dictionary, those definitions are overridden by "run_path()".

   The special global variables "__name__", "__file__", "__loader__"
   and "__package__" are set in the globals dictionary before the
   module code is executed (Note that this is a minimal set of
   variables - other variables may be set implicitly as an interpreter
   implementation detail).

   "__name__" is set to *run_name* if this optional argument is not
   "None" and to "'<run_path>'" otherwise.

   "__file__" is set to the name provided by the module loader. If the
   loader does not make filename information available, this variable
   is set to "None". For a simple script, this will be set to
   "file_path".

   "__loader__" is set to the **PEP 302** module loader used to
   retrieve the code for the module (This loader may be a wrapper
   around the standard import mechanism). For a simple script, this
   will be set to "None".

   "__package__" is set to "__name__.rpartition('.')[0]".

   A number of alterations are also made to the "sys" module. Firstly,
   "sys.path" may be altered as described above. "sys.argv[0]" is
   updated with the value of "file_path" and "sys.modules[__name__]"
   is updated with a temporary module object for the module being
   executed. All modifications to items in "sys" are reverted before
   the function returns.

   Note that, unlike "run_module()", the alterations made to "sys" are
   not optional in this function as these adjustments are essential to
   allowing the execution of sys.path entries. As the thread-safety
   limitations still apply, use of this function in threaded code
   should be either serialised with the import lock or delegated to a
   separate process.

   Ver também: Interface options for equivalent functionality on the
     command line ("python path/to/script").

   Novo na versão 2.7.

Ver também:

  **PEP 338** – Executing modules as scripts
     PEP written and implemented by Nick Coghlan.

  **PEP 366** – Main module explicit relative imports
     PEP written and implemented by Nick Coghlan.

  Command line and environment - CPython command line details
