Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1 | |
| 2 | .. _execmodel: |
| 3 | |
| 4 | *************** |
| 5 | Execution model |
| 6 | *************** |
| 7 | |
| 8 | .. index:: single: execution model |
| 9 | |
| 10 | |
| 11 | .. _naming: |
| 12 | |
| 13 | Naming and binding |
| 14 | ================== |
| 15 | |
| 16 | .. index:: |
| 17 | pair: code; block |
| 18 | single: namespace |
| 19 | single: scope |
| 20 | |
| 21 | .. index:: |
| 22 | single: name |
| 23 | pair: binding; name |
| 24 | |
| 25 | :dfn:`Names` refer to objects. Names are introduced by name binding operations. |
| 26 | Each occurrence of a name in the program text refers to the :dfn:`binding` of |
| 27 | that name established in the innermost function block containing the use. |
| 28 | |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 29 | .. index:: block |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 30 | |
| 31 | A :dfn:`block` is a piece of Python program text that is executed as a unit. |
| 32 | The following are blocks: a module, a function body, and a class definition. |
| 33 | Each command typed interactively is a block. A script file (a file given as |
| 34 | standard input to the interpreter or specified on the interpreter command line |
| 35 | the first argument) is a code block. A script command (a command specified on |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 36 | the interpreter command line with the '**-c**' option) is a code block. The |
| 37 | string argument passed to the built-in functions :func:`eval` and :func:`exec` |
| 38 | is a code block. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 39 | |
| 40 | .. index:: pair: execution; frame |
| 41 | |
| 42 | A code block is executed in an :dfn:`execution frame`. A frame contains some |
| 43 | administrative information (used for debugging) and determines where and how |
| 44 | execution continues after the code block's execution has completed. |
| 45 | |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 46 | .. index:: scope |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 47 | |
| 48 | A :dfn:`scope` defines the visibility of a name within a block. If a local |
| 49 | variable is defined in a block, its scope includes that block. If the |
| 50 | definition occurs in a function block, the scope extends to any blocks contained |
| 51 | within the defining one, unless a contained block introduces a different binding |
| 52 | for the name. The scope of names defined in a class block is limited to the |
Christian Heimes | 04c420f | 2008-01-18 18:40:46 +0000 | [diff] [blame] | 53 | class block; it does not extend to the code blocks of methods -- this includes |
Benjamin Peterson | e9deddb | 2009-01-31 03:57:19 +0000 | [diff] [blame] | 54 | comprehensions and generator expressions since they are implemented using a |
| 55 | function scope. This means that the following will fail:: |
Christian Heimes | 04c420f | 2008-01-18 18:40:46 +0000 | [diff] [blame] | 56 | |
| 57 | class A: |
| 58 | a = 42 |
| 59 | b = list(a + i for i in range(10)) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 60 | |
| 61 | .. index:: single: environment |
| 62 | |
| 63 | When a name is used in a code block, it is resolved using the nearest enclosing |
| 64 | scope. The set of all such scopes visible to a code block is called the block's |
| 65 | :dfn:`environment`. |
| 66 | |
| 67 | .. index:: pair: free; variable |
| 68 | |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 69 | If a name is bound in a block, it is a local variable of that block, unless |
| 70 | declared as :keyword:`nonlocal`. If a name is bound at the module level, it is |
| 71 | a global variable. (The variables of the module code block are local and |
| 72 | global.) If a variable is used in a code block but not defined there, it is a |
| 73 | :dfn:`free variable`. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 74 | |
| 75 | .. index:: |
| 76 | single: NameError (built-in exception) |
| 77 | single: UnboundLocalError |
| 78 | |
| 79 | When a name is not found at all, a :exc:`NameError` exception is raised. If the |
| 80 | name refers to a local variable that has not been bound, a |
| 81 | :exc:`UnboundLocalError` exception is raised. :exc:`UnboundLocalError` is a |
| 82 | subclass of :exc:`NameError`. |
| 83 | |
| 84 | .. index:: statement: from |
| 85 | |
| 86 | The following constructs bind names: formal parameters to functions, |
| 87 | :keyword:`import` statements, class and function definitions (these bind the |
| 88 | class or function name in the defining block), and targets that are identifiers |
Georg Brandl | 7f15786 | 2009-03-15 21:57:20 +0000 | [diff] [blame] | 89 | if occurring in an assignment, :keyword:`for` loop header, or after |
| 90 | :keyword:`as` in a :keyword:`with` statement or :keyword.`except` clause. |
| 91 | The :keyword:`import` statement |
| 92 | of the form ``from ... import *`` binds all names defined in the imported |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 93 | module, except those beginning with an underscore. This form may only be used |
| 94 | at the module level. |
| 95 | |
| 96 | A target occurring in a :keyword:`del` statement is also considered bound for |
| 97 | this purpose (though the actual semantics are to unbind the name). It is |
| 98 | illegal to unbind a name that is referenced by an enclosing scope; the compiler |
| 99 | will report a :exc:`SyntaxError`. |
| 100 | |
| 101 | Each assignment or import statement occurs within a block defined by a class or |
| 102 | function definition or at the module level (the top-level code block). |
| 103 | |
| 104 | If a name binding operation occurs anywhere within a code block, all uses of the |
| 105 | name within the block are treated as references to the current block. This can |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 106 | lead to errors when a name is used within a block before it is bound. This rule |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 107 | is subtle. Python lacks declarations and allows name binding operations to |
| 108 | occur anywhere within a code block. The local variables of a code block can be |
| 109 | determined by scanning the entire text of the block for name binding operations. |
| 110 | |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 111 | If the :keyword:`global` statement occurs within a block, all uses of the name |
| 112 | specified in the statement refer to the binding of that name in the top-level |
| 113 | namespace. Names are resolved in the top-level namespace by searching the |
| 114 | global namespace, i.e. the namespace of the module containing the code block, |
Georg Brandl | 22b3431 | 2009-07-26 14:54:51 +0000 | [diff] [blame] | 115 | and the builtins namespace, the namespace of the module :mod:`builtins`. The |
| 116 | global namespace is searched first. If the name is not found there, the builtins |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 117 | namespace is searched. The global statement must precede all uses of the name. |
| 118 | |
| 119 | .. XXX document "nonlocal" semantics here |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 120 | |
| 121 | .. index:: pair: restricted; execution |
| 122 | |
Georg Brandl | 93dc9eb | 2010-03-14 10:56:14 +0000 | [diff] [blame] | 123 | The builtins namespace associated with the execution of a code block is actually |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 124 | found by looking up the name ``__builtins__`` in its global namespace; this |
| 125 | should be a dictionary or a module (in the latter case the module's dictionary |
| 126 | is used). By default, when in the :mod:`__main__` module, ``__builtins__`` is |
Georg Brandl | 1a3284e | 2007-12-02 09:40:06 +0000 | [diff] [blame] | 127 | the built-in module :mod:`builtins`; when in any other module, |
| 128 | ``__builtins__`` is an alias for the dictionary of the :mod:`builtins` module |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 129 | itself. ``__builtins__`` can be set to a user-created dictionary to create a |
| 130 | weak form of restricted execution. |
| 131 | |
Georg Brandl | 495f7b5 | 2009-10-27 15:28:25 +0000 | [diff] [blame] | 132 | .. impl-detail:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 133 | |
| 134 | Users should not touch ``__builtins__``; it is strictly an implementation |
Georg Brandl | 93dc9eb | 2010-03-14 10:56:14 +0000 | [diff] [blame] | 135 | detail. Users wanting to override values in the builtins namespace should |
Georg Brandl | 1a3284e | 2007-12-02 09:40:06 +0000 | [diff] [blame] | 136 | :keyword:`import` the :mod:`builtins` module and modify its |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 137 | attributes appropriately. |
| 138 | |
| 139 | .. index:: module: __main__ |
| 140 | |
| 141 | The namespace for a module is automatically created the first time a module is |
| 142 | imported. The main module for a script is always called :mod:`__main__`. |
| 143 | |
| 144 | The global statement has the same scope as a name binding operation in the same |
| 145 | block. If the nearest enclosing scope for a free variable contains a global |
| 146 | statement, the free variable is treated as a global. |
| 147 | |
| 148 | A class definition is an executable statement that may use and define names. |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 149 | These references follow the normal rules for name resolution. The namespace of |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 150 | the class definition becomes the attribute dictionary of the class. Names |
| 151 | defined at the class scope are not visible in methods. |
| 152 | |
| 153 | |
| 154 | .. _dynamic-features: |
| 155 | |
| 156 | Interaction with dynamic features |
| 157 | --------------------------------- |
| 158 | |
| 159 | There are several cases where Python statements are illegal when used in |
| 160 | conjunction with nested scopes that contain free variables. |
| 161 | |
| 162 | If a variable is referenced in an enclosing scope, it is illegal to delete the |
| 163 | name. An error will be reported at compile time. |
| 164 | |
| 165 | If the wild card form of import --- ``import *`` --- is used in a function and |
| 166 | the function contains or is a nested block with free variables, the compiler |
| 167 | will raise a :exc:`SyntaxError`. |
| 168 | |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 169 | .. XXX from * also invalid with relative imports (at least currently) |
| 170 | |
| 171 | The :func:`eval` and :func:`exec` functions do not have access to the full |
| 172 | environment for resolving names. Names may be resolved in the local and global |
| 173 | namespaces of the caller. Free variables are not resolved in the nearest |
| 174 | enclosing namespace, but in the global namespace. [#]_ The :func:`exec` and |
| 175 | :func:`eval` functions have optional arguments to override the global and local |
| 176 | namespace. If only one namespace is specified, it is used for both. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 177 | |
| 178 | |
| 179 | .. _exceptions: |
| 180 | |
| 181 | Exceptions |
| 182 | ========== |
| 183 | |
| 184 | .. index:: single: exception |
| 185 | |
| 186 | .. index:: |
| 187 | single: raise an exception |
| 188 | single: handle an exception |
| 189 | single: exception handler |
| 190 | single: errors |
| 191 | single: error handling |
| 192 | |
| 193 | Exceptions are a means of breaking out of the normal flow of control of a code |
| 194 | block in order to handle errors or other exceptional conditions. An exception |
| 195 | is *raised* at the point where the error is detected; it may be *handled* by the |
| 196 | surrounding code block or by any code block that directly or indirectly invoked |
| 197 | the code block where the error occurred. |
| 198 | |
| 199 | The Python interpreter raises an exception when it detects a run-time error |
| 200 | (such as division by zero). A Python program can also explicitly raise an |
| 201 | exception with the :keyword:`raise` statement. Exception handlers are specified |
Alexandre Vassalotti | eca20b6 | 2008-05-16 02:54:33 +0000 | [diff] [blame] | 202 | with the :keyword:`try` ... :keyword:`except` statement. The :keyword:`finally` |
| 203 | clause of such a statement can be used to specify cleanup code which does not |
| 204 | handle the exception, but is executed whether an exception occurred or not in |
| 205 | the preceding code. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 206 | |
| 207 | .. index:: single: termination model |
| 208 | |
| 209 | Python uses the "termination" model of error handling: an exception handler can |
| 210 | find out what happened and continue execution at an outer level, but it cannot |
| 211 | repair the cause of the error and retry the failing operation (except by |
| 212 | re-entering the offending piece of code from the top). |
| 213 | |
| 214 | .. index:: single: SystemExit (built-in exception) |
| 215 | |
| 216 | When an exception is not handled at all, the interpreter terminates execution of |
| 217 | the program, or returns to its interactive main loop. In either case, it prints |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 218 | a stack backtrace, except when the exception is :exc:`SystemExit`. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 219 | |
| 220 | Exceptions are identified by class instances. The :keyword:`except` clause is |
| 221 | selected depending on the class of the instance: it must reference the class of |
| 222 | the instance or a base class thereof. The instance can be received by the |
| 223 | handler and can carry additional information about the exceptional condition. |
| 224 | |
Georg Brandl | e720c0a | 2009-04-27 16:20:50 +0000 | [diff] [blame] | 225 | .. note:: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 226 | |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 227 | Exception messages are not part of the Python API. Their contents may change |
| 228 | from one version of Python to the next without warning and should not be |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 229 | relied on by code which will run under multiple versions of the interpreter. |
| 230 | |
| 231 | See also the description of the :keyword:`try` statement in section :ref:`try` |
| 232 | and :keyword:`raise` statement in section :ref:`raise`. |
| 233 | |
Georg Brandl | 1aea30a | 2008-07-19 15:51:07 +0000 | [diff] [blame] | 234 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 235 | .. rubric:: Footnotes |
| 236 | |
Georg Brandl | 96593ed | 2007-09-07 14:15:41 +0000 | [diff] [blame] | 237 | .. [#] This limitation occurs because the code that is executed by these operations |
| 238 | is not available at the time the module is compiled. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 239 | |