2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
.. _execmodel:
|
|
|
|
|
|
|
|
***************
|
|
|
|
Execution model
|
|
|
|
***************
|
|
|
|
|
|
|
|
.. index:: single: execution model
|
|
|
|
|
|
|
|
|
|
|
|
.. _naming:
|
|
|
|
|
|
|
|
Naming and binding
|
|
|
|
==================
|
|
|
|
|
|
|
|
.. index::
|
|
|
|
pair: code; block
|
|
|
|
single: namespace
|
|
|
|
single: scope
|
|
|
|
|
|
|
|
.. index::
|
|
|
|
single: name
|
|
|
|
pair: binding; name
|
|
|
|
|
|
|
|
:dfn:`Names` refer to objects. Names are introduced by name binding operations.
|
|
|
|
Each occurrence of a name in the program text refers to the :dfn:`binding` of
|
|
|
|
that name established in the innermost function block containing the use.
|
|
|
|
|
|
|
|
.. index:: single: block
|
|
|
|
|
|
|
|
A :dfn:`block` is a piece of Python program text that is executed as a unit.
|
|
|
|
The following are blocks: a module, a function body, and a class definition.
|
|
|
|
Each command typed interactively is a block. A script file (a file given as
|
|
|
|
standard input to the interpreter or specified on the interpreter command line
|
|
|
|
the first argument) is a code block. A script command (a command specified on
|
|
|
|
the interpreter command line with the '**-c**' option) is a code block. The
|
|
|
|
file read by the built-in function :func:`execfile` is a code block. The string
|
|
|
|
argument passed to the built-in function :func:`eval` and to the :keyword:`exec`
|
|
|
|
statement is a code block. The expression read and evaluated by the built-in
|
|
|
|
function :func:`input` is a code block.
|
|
|
|
|
|
|
|
.. index:: pair: execution; frame
|
|
|
|
|
|
|
|
A code block is executed in an :dfn:`execution frame`. A frame contains some
|
|
|
|
administrative information (used for debugging) and determines where and how
|
|
|
|
execution continues after the code block's execution has completed.
|
|
|
|
|
|
|
|
.. index:: single: scope
|
|
|
|
|
|
|
|
A :dfn:`scope` defines the visibility of a name within a block. If a local
|
|
|
|
variable is defined in a block, its scope includes that block. If the
|
|
|
|
definition occurs in a function block, the scope extends to any blocks contained
|
|
|
|
within the defining one, unless a contained block introduces a different binding
|
|
|
|
for the name. The scope of names defined in a class block is limited to the
|
2008-01-18 12:42:57 -04:00
|
|
|
class block; it does not extend to the code blocks of methods -- this includes
|
|
|
|
generator expressions since they are implemented using a function scope. This
|
|
|
|
means that the following will fail::
|
|
|
|
|
|
|
|
class A:
|
|
|
|
a = 42
|
|
|
|
b = list(a + i for i in range(10))
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
.. index:: single: environment
|
|
|
|
|
|
|
|
When a name is used in a code block, it is resolved using the nearest enclosing
|
|
|
|
scope. The set of all such scopes visible to a code block is called the block's
|
|
|
|
:dfn:`environment`.
|
|
|
|
|
|
|
|
.. index:: pair: free; variable
|
|
|
|
|
|
|
|
If a name is bound in a block, it is a local variable of that block. If a name
|
|
|
|
is bound at the module level, it is a global variable. (The variables of the
|
|
|
|
module code block are local and global.) If a variable is used in a code block
|
|
|
|
but not defined there, it is a :dfn:`free variable`.
|
|
|
|
|
|
|
|
.. index::
|
|
|
|
single: NameError (built-in exception)
|
|
|
|
single: UnboundLocalError
|
|
|
|
|
|
|
|
When a name is not found at all, a :exc:`NameError` exception is raised. If the
|
|
|
|
name refers to a local variable that has not been bound, a
|
|
|
|
:exc:`UnboundLocalError` exception is raised. :exc:`UnboundLocalError` is a
|
|
|
|
subclass of :exc:`NameError`.
|
|
|
|
|
|
|
|
.. index:: statement: from
|
|
|
|
|
|
|
|
The following constructs bind names: formal parameters to functions,
|
|
|
|
:keyword:`import` statements, class and function definitions (these bind the
|
|
|
|
class or function name in the defining block), and targets that are identifiers
|
Merged revisions 69578-69580,69901,69907,69994,70022-70023,70025-70026,70166,70273,70275,70342,70386-70387,70389-70390,70392-70393,70395,70397,70400,70418 via svnmerge
........
r69578 | georg.brandl | 2009-02-13 12:03:59 +0100 (Fr, 13 Feb 2009) | 1 line
#3694: add test for fix committed in r66693.
........
r69579 | georg.brandl | 2009-02-13 12:06:59 +0100 (Fr, 13 Feb 2009) | 2 lines
Fix warnings GCC emits where the argument of PyErr_Format is a single variable.
........
r69580 | georg.brandl | 2009-02-13 12:10:04 +0100 (Fr, 13 Feb 2009) | 2 lines
Fix warnings GCC emits where the argument of PyErr_Format is a single variable.
........
r69901 | georg.brandl | 2009-02-23 12:24:46 +0100 (Mo, 23 Feb 2009) | 2 lines
#5349: C++ pure virtuals can also have an implementation.
........
r69907 | georg.brandl | 2009-02-23 19:33:48 +0100 (Mo, 23 Feb 2009) | 1 line
Fix grammar.
........
r69994 | georg.brandl | 2009-02-26 18:36:26 +0100 (Do, 26 Feb 2009) | 1 line
Document that setting sys.py3kwarning wont do anything.
........
r70022 | georg.brandl | 2009-02-27 17:23:18 +0100 (Fr, 27 Feb 2009) | 1 line
#5361: fix typo.
........
r70023 | georg.brandl | 2009-02-27 17:39:26 +0100 (Fr, 27 Feb 2009) | 1 line
#5363: fix cmpfiles() docs. Another instance where a prose description is twice as long as the code.
........
r70025 | georg.brandl | 2009-02-27 17:52:55 +0100 (Fr, 27 Feb 2009) | 1 line
#5344: fix punctuation.
........
r70026 | georg.brandl | 2009-02-27 17:59:03 +0100 (Fr, 27 Feb 2009) | 1 line
#5365: add quick look conversion table for different time representations.
........
r70166 | georg.brandl | 2009-03-04 19:24:41 +0100 (Mi, 04 Mär 2009) | 2 lines
Remove obsolete stuff from string module docs.
........
r70273 | georg.brandl | 2009-03-09 15:25:07 +0100 (Mo, 09 Mär 2009) | 2 lines
#5458: add a note when we started to raise RuntimeErrors.
........
r70275 | georg.brandl | 2009-03-09 17:35:48 +0100 (Mo, 09 Mär 2009) | 2 lines
Add missing space.
........
r70342 | georg.brandl | 2009-03-13 20:03:58 +0100 (Fr, 13 Mär 2009) | 1 line
#5486: typos.
........
r70386 | georg.brandl | 2009-03-15 22:32:06 +0100 (So, 15 Mär 2009) | 1 line
#5496: fix docstring of lookup().
........
r70387 | georg.brandl | 2009-03-15 22:37:16 +0100 (So, 15 Mär 2009) | 1 line
#5493: clarify __nonzero__ docs.
........
r70389 | georg.brandl | 2009-03-15 22:43:38 +0100 (So, 15 Mär 2009) | 1 line
Fix a small nit in the error message if bool() falls back on __len__ and it returns the wrong type: it would tell the user that __nonzero__ should return bool or int.
........
r70390 | georg.brandl | 2009-03-15 22:44:43 +0100 (So, 15 Mär 2009) | 1 line
#5491: clarify nested() semantics.
........
r70392 | georg.brandl | 2009-03-15 22:46:00 +0100 (So, 15 Mär 2009) | 1 line
#5488: add missing struct member.
........
r70393 | georg.brandl | 2009-03-15 22:47:42 +0100 (So, 15 Mär 2009) | 1 line
#5478: fix copy-paste oversight in function signature.
........
r70395 | georg.brandl | 2009-03-15 22:51:48 +0100 (So, 15 Mär 2009) | 1 line
#5276: document IDLESTARTUP and .Idle.py.
........
r70397 | georg.brandl | 2009-03-15 22:53:56 +0100 (So, 15 Mär 2009) | 1 line
#5469: add with statement to list of name-binding constructs.
........
r70400 | georg.brandl | 2009-03-15 22:59:37 +0100 (So, 15 Mär 2009) | 3 lines
Fix markup in re docs and give a mail address in regex howto, so that
the recommendation to send suggestions to the author can be followed.
........
r70418 | georg.brandl | 2009-03-16 20:42:03 +0100 (Mo, 16 Mär 2009) | 1 line
Add token markup.
........
2009-04-05 18:48:06 -03:00
|
|
|
if occurring in an assignment, :keyword:`for` loop header, in the second
|
|
|
|
position of an :keyword:`except` clause header or after :keyword:`as` in a
|
|
|
|
:keyword:`with` statement. The :keyword:`import` statement
|
|
|
|
of the form ``from ... import *`` binds all names defined in the imported
|
2007-08-15 11:28:01 -03:00
|
|
|
module, except those beginning with an underscore. This form may only be used
|
|
|
|
at the module level.
|
|
|
|
|
|
|
|
A target occurring in a :keyword:`del` statement is also considered bound for
|
|
|
|
this purpose (though the actual semantics are to unbind the name). It is
|
|
|
|
illegal to unbind a name that is referenced by an enclosing scope; the compiler
|
|
|
|
will report a :exc:`SyntaxError`.
|
|
|
|
|
|
|
|
Each assignment or import statement occurs within a block defined by a class or
|
|
|
|
function definition or at the module level (the top-level code block).
|
|
|
|
|
|
|
|
If a name binding operation occurs anywhere within a code block, all uses of the
|
|
|
|
name within the block are treated as references to the current block. This can
|
|
|
|
lead to errors when a name is used within a block before it is bound. This rule
|
|
|
|
is subtle. Python lacks declarations and allows name binding operations to
|
|
|
|
occur anywhere within a code block. The local variables of a code block can be
|
|
|
|
determined by scanning the entire text of the block for name binding operations.
|
|
|
|
|
|
|
|
If the global statement occurs within a block, all uses of the name specified in
|
|
|
|
the statement refer to the binding of that name in the top-level namespace.
|
|
|
|
Names are resolved in the top-level namespace by searching the global namespace,
|
|
|
|
i.e. the namespace of the module containing the code block, and the builtin
|
|
|
|
namespace, the namespace of the module :mod:`__builtin__`. The global namespace
|
|
|
|
is searched first. If the name is not found there, the builtin namespace is
|
|
|
|
searched. The global statement must precede all uses of the name.
|
|
|
|
|
|
|
|
.. index:: pair: restricted; execution
|
|
|
|
|
|
|
|
The built-in namespace associated with the execution of a code block is actually
|
|
|
|
found by looking up the name ``__builtins__`` in its global namespace; this
|
|
|
|
should be a dictionary or a module (in the latter case the module's dictionary
|
|
|
|
is used). By default, when in the :mod:`__main__` module, ``__builtins__`` is
|
|
|
|
the built-in module :mod:`__builtin__` (note: no 's'); when in any other module,
|
|
|
|
``__builtins__`` is an alias for the dictionary of the :mod:`__builtin__` module
|
|
|
|
itself. ``__builtins__`` can be set to a user-created dictionary to create a
|
|
|
|
weak form of restricted execution.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Users should not touch ``__builtins__``; it is strictly an implementation
|
|
|
|
detail. Users wanting to override values in the built-in namespace should
|
|
|
|
:keyword:`import` the :mod:`__builtin__` (no 's') module and modify its
|
|
|
|
attributes appropriately.
|
|
|
|
|
|
|
|
.. index:: module: __main__
|
|
|
|
|
|
|
|
The namespace for a module is automatically created the first time a module is
|
|
|
|
imported. The main module for a script is always called :mod:`__main__`.
|
|
|
|
|
|
|
|
The global statement has the same scope as a name binding operation in the same
|
|
|
|
block. If the nearest enclosing scope for a free variable contains a global
|
|
|
|
statement, the free variable is treated as a global.
|
|
|
|
|
|
|
|
A class definition is an executable statement that may use and define names.
|
|
|
|
These references follow the normal rules for name resolution. The namespace of
|
|
|
|
the class definition becomes the attribute dictionary of the class. Names
|
|
|
|
defined at the class scope are not visible in methods.
|
|
|
|
|
|
|
|
|
|
|
|
.. _dynamic-features:
|
|
|
|
|
|
|
|
Interaction with dynamic features
|
|
|
|
---------------------------------
|
|
|
|
|
|
|
|
There are several cases where Python statements are illegal when used in
|
|
|
|
conjunction with nested scopes that contain free variables.
|
|
|
|
|
|
|
|
If a variable is referenced in an enclosing scope, it is illegal to delete the
|
|
|
|
name. An error will be reported at compile time.
|
|
|
|
|
|
|
|
If the wild card form of import --- ``import *`` --- is used in a function and
|
|
|
|
the function contains or is a nested block with free variables, the compiler
|
|
|
|
will raise a :exc:`SyntaxError`.
|
|
|
|
|
|
|
|
If :keyword:`exec` is used in a function and the function contains or is a
|
|
|
|
nested block with free variables, the compiler will raise a :exc:`SyntaxError`
|
|
|
|
unless the exec explicitly specifies the local namespace for the
|
|
|
|
:keyword:`exec`. (In other words, ``exec obj`` would be illegal, but ``exec obj
|
|
|
|
in ns`` would be legal.)
|
|
|
|
|
|
|
|
The :func:`eval`, :func:`execfile`, and :func:`input` functions and the
|
|
|
|
:keyword:`exec` statement do not have access to the full environment for
|
|
|
|
resolving names. Names may be resolved in the local and global namespaces of
|
|
|
|
the caller. Free variables are not resolved in the nearest enclosing namespace,
|
|
|
|
but in the global namespace. [#]_ The :keyword:`exec` statement and the
|
|
|
|
:func:`eval` and :func:`execfile` functions have optional arguments to override
|
|
|
|
the global and local namespace. If only one namespace is specified, it is used
|
|
|
|
for both.
|
|
|
|
|
|
|
|
|
|
|
|
.. _exceptions:
|
|
|
|
|
|
|
|
Exceptions
|
|
|
|
==========
|
|
|
|
|
|
|
|
.. index:: single: exception
|
|
|
|
|
|
|
|
.. index::
|
|
|
|
single: raise an exception
|
|
|
|
single: handle an exception
|
|
|
|
single: exception handler
|
|
|
|
single: errors
|
|
|
|
single: error handling
|
|
|
|
|
|
|
|
Exceptions are a means of breaking out of the normal flow of control of a code
|
|
|
|
block in order to handle errors or other exceptional conditions. An exception
|
|
|
|
is *raised* at the point where the error is detected; it may be *handled* by the
|
|
|
|
surrounding code block or by any code block that directly or indirectly invoked
|
|
|
|
the code block where the error occurred.
|
|
|
|
|
|
|
|
The Python interpreter raises an exception when it detects a run-time error
|
|
|
|
(such as division by zero). A Python program can also explicitly raise an
|
|
|
|
exception with the :keyword:`raise` statement. Exception handlers are specified
|
2008-05-12 14:14:51 -03:00
|
|
|
with the :keyword:`try` ... :keyword:`except` statement. The :keyword:`finally`
|
|
|
|
clause of such a statement can be used to specify cleanup code which does not
|
|
|
|
handle the exception, but is executed whether an exception occurred or not in
|
|
|
|
the preceding code.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
.. index:: single: termination model
|
|
|
|
|
|
|
|
Python uses the "termination" model of error handling: an exception handler can
|
|
|
|
find out what happened and continue execution at an outer level, but it cannot
|
|
|
|
repair the cause of the error and retry the failing operation (except by
|
|
|
|
re-entering the offending piece of code from the top).
|
|
|
|
|
|
|
|
.. index:: single: SystemExit (built-in exception)
|
|
|
|
|
|
|
|
When an exception is not handled at all, the interpreter terminates execution of
|
|
|
|
the program, or returns to its interactive main loop. In either case, it prints
|
|
|
|
a stack backtrace, except when the exception is :exc:`SystemExit`.
|
|
|
|
|
|
|
|
Exceptions are identified by class instances. The :keyword:`except` clause is
|
|
|
|
selected depending on the class of the instance: it must reference the class of
|
|
|
|
the instance or a base class thereof. The instance can be received by the
|
|
|
|
handler and can carry additional information about the exceptional condition.
|
|
|
|
|
|
|
|
Exceptions can also be identified by strings, in which case the
|
|
|
|
:keyword:`except` clause is selected by object identity. An arbitrary value can
|
|
|
|
be raised along with the identifying string which can be passed to the handler.
|
|
|
|
|
Merged revisions 72007-72010,72036-72037 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72007 | georg.brandl | 2009-04-27 17:09:25 +0200 (Mo, 27 Apr 2009) | 1 line
#5856: fix typo s in traceback example.
........
r72008 | georg.brandl | 2009-04-27 17:10:44 +0200 (Mo, 27 Apr 2009) | 1 line
Remove ".. warning::" markup that doesnt contain warnings for users, rather todo items.
........
r72009 | georg.brandl | 2009-04-27 17:29:09 +0200 (Mo, 27 Apr 2009) | 3 lines
Demote warnings to notices where appropriate, following the goal that as few "red box" warnings
should clutter the docs as possible. Part 1: stuff that gets merged to Py3k.
........
r72010 | georg.brandl | 2009-04-27 17:29:26 +0200 (Mo, 27 Apr 2009) | 2 lines
Demote warnings to notices, part 2: stuff that is 2.x-only.
........
r72036 | georg.brandl | 2009-04-27 19:04:23 +0200 (Mo, 27 Apr 2009) | 1 line
#5848: small unittest doc patch.
........
r72037 | georg.brandl | 2009-04-27 19:09:53 +0200 (Mo, 27 Apr 2009) | 1 line
#5840: dont claim we dont support TLS.
........
2009-04-28 15:23:28 -03:00
|
|
|
.. note::
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
Messages to exceptions are not part of the Python API. Their contents may
|
|
|
|
change from one version of Python to the next without warning and should not be
|
|
|
|
relied on by code which will run under multiple versions of the interpreter.
|
|
|
|
|
|
|
|
See also the description of the :keyword:`try` statement in section :ref:`try`
|
|
|
|
and :keyword:`raise` statement in section :ref:`raise`.
|
|
|
|
|
|
|
|
.. rubric:: Footnotes
|
|
|
|
|
|
|
|
.. [#] This limitation occurs because the code that is executed by these operations is
|
|
|
|
not available at the time the module is compiled.
|
|
|
|
|