1 | \chapter{Execution model \label{execmodel}}
|
---|
2 | \index{execution model}
|
---|
3 |
|
---|
4 |
|
---|
5 | \section{Naming and binding \label{naming}}
|
---|
6 | \indexii{code}{block}
|
---|
7 | \index{namespace}
|
---|
8 | \index{scope}
|
---|
9 |
|
---|
10 | \dfn{Names}\index{name} refer to objects. Names are introduced by
|
---|
11 | name binding operations. Each occurrence of a name in the program
|
---|
12 | text refers to the \dfn{binding}\indexii{binding}{name} of that name
|
---|
13 | established in the innermost function block containing the use.
|
---|
14 |
|
---|
15 | A \dfn{block}\index{block} is a piece of Python program text that is
|
---|
16 | executed as a unit. The following are blocks: a module, a function
|
---|
17 | body, and a class definition. Each command typed interactively is a
|
---|
18 | block. A script file (a file given as standard input to the
|
---|
19 | interpreter or specified on the interpreter command line the first
|
---|
20 | argument) is a code block. A script command (a command specified on
|
---|
21 | the interpreter command line with the `\strong{-c}' option) is a code
|
---|
22 | block. The file read by the built-in function \function{execfile()}
|
---|
23 | is a code block. The string argument passed to the built-in function
|
---|
24 | \function{eval()} and to the \keyword{exec} statement is a code block.
|
---|
25 | The expression read and evaluated by the built-in function
|
---|
26 | \function{input()} is a code block.
|
---|
27 |
|
---|
28 | A code block is executed in an \dfn{execution
|
---|
29 | frame}\indexii{execution}{frame}. A frame contains some
|
---|
30 | administrative information (used for debugging) and determines where
|
---|
31 | and how execution continues after the code block's execution has
|
---|
32 | completed.
|
---|
33 |
|
---|
34 | A \dfn{scope}\index{scope} defines the visibility of a name within a
|
---|
35 | block. If a local variable is defined in a block, its scope includes
|
---|
36 | that block. If the definition occurs in a function block, the scope
|
---|
37 | extends to any blocks contained within the defining one, unless a
|
---|
38 | contained block introduces a different binding for the name. The
|
---|
39 | scope of names defined in a class block is limited to the class block;
|
---|
40 | it does not extend to the code blocks of methods.
|
---|
41 |
|
---|
42 | When a name is used in a code block, it is resolved using the nearest
|
---|
43 | enclosing scope. The set of all such scopes visible to a code block
|
---|
44 | is called the block's \dfn{environment}\index{environment}.
|
---|
45 |
|
---|
46 | If a name is bound in a block, it is a local variable of that block.
|
---|
47 | If a name is bound at the module level, it is a global variable. (The
|
---|
48 | variables of the module code block are local and global.) If a
|
---|
49 | variable is used in a code block but not defined there, it is a
|
---|
50 | \dfn{free variable}\indexii{free}{variable}.
|
---|
51 |
|
---|
52 | When a name is not found at all, a
|
---|
53 | \exception{NameError}\withsubitem{(built-in
|
---|
54 | exception)}{\ttindex{NameError}} exception is raised. If the name
|
---|
55 | refers to a local variable that has not been bound, a
|
---|
56 | \exception{UnboundLocalError}\ttindex{UnboundLocalError} exception is
|
---|
57 | raised. \exception{UnboundLocalError} is a subclass of
|
---|
58 | \exception{NameError}.
|
---|
59 |
|
---|
60 | The following constructs bind names: formal parameters to functions,
|
---|
61 | \keyword{import} statements, class and function definitions (these
|
---|
62 | bind the class or function name in the defining block), and targets
|
---|
63 | that are identifiers if occurring in an assignment, \keyword{for} loop
|
---|
64 | header, or in the second position of an \keyword{except} clause
|
---|
65 | header. The \keyword{import} statement of the form ``\samp{from
|
---|
66 | \ldots import *}''\stindex{from} binds all names defined in the
|
---|
67 | imported module, except those beginning with an underscore. This form
|
---|
68 | may only be used at the module level.
|
---|
69 |
|
---|
70 | A target occurring in a \keyword{del} statement is also considered bound
|
---|
71 | for this purpose (though the actual semantics are to unbind the
|
---|
72 | name). It is illegal to unbind a name that is referenced by an
|
---|
73 | enclosing scope; the compiler will report a \exception{SyntaxError}.
|
---|
74 |
|
---|
75 | Each assignment or import statement occurs within a block defined by a
|
---|
76 | class or function definition or at the module level (the top-level
|
---|
77 | code block).
|
---|
78 |
|
---|
79 | If a name binding operation occurs anywhere within a code block, all
|
---|
80 | uses of the name within the block are treated as references to the
|
---|
81 | current block. This can lead to errors when a name is used within a
|
---|
82 | block before it is bound.
|
---|
83 | This rule is subtle. Python lacks declarations and allows
|
---|
84 | name binding operations to occur anywhere within a code block. The
|
---|
85 | local variables of a code block can be determined by scanning the
|
---|
86 | entire text of the block for name binding operations.
|
---|
87 |
|
---|
88 | If the global statement occurs within a block, all uses of the name
|
---|
89 | specified in the statement refer to the binding of that name in the
|
---|
90 | top-level namespace. Names are resolved in the top-level namespace by
|
---|
91 | searching the global namespace, i.e. the namespace of the module
|
---|
92 | containing the code block, and the builtin namespace, the namespace of
|
---|
93 | the module \module{__builtin__}. The global namespace is searched
|
---|
94 | first. If the name is not found there, the builtin namespace is
|
---|
95 | searched. The global statement must precede all uses of the name.
|
---|
96 |
|
---|
97 | The built-in namespace associated with the execution of a code block
|
---|
98 | is actually found by looking up the name \code{__builtins__} in its
|
---|
99 | global namespace; this should be a dictionary or a module (in the
|
---|
100 | latter case the module's dictionary is used). By default, when in the
|
---|
101 | \module{__main__} module, \code{__builtins__} is the built-in module
|
---|
102 | \module{__builtin__} (note: no `s'); when in any other module,
|
---|
103 | \code{__builtins__} is an alias for the dictionary of the
|
---|
104 | \module{__builtin__} module itself. \code{__builtins__} can be set
|
---|
105 | to a user-created dictionary to create a weak form of restricted
|
---|
106 | execution\indexii{restricted}{execution}.
|
---|
107 |
|
---|
108 | \begin{notice}
|
---|
109 | Users should not touch \code{__builtins__}; it is strictly an
|
---|
110 | implementation detail. Users wanting to override values in the
|
---|
111 | built-in namespace should \keyword{import} the \module{__builtin__}
|
---|
112 | (no `s') module and modify its attributes appropriately.
|
---|
113 | \end{notice}
|
---|
114 |
|
---|
115 | The namespace for a module is automatically created the first time a
|
---|
116 | module is imported. The main module for a script is always called
|
---|
117 | \module{__main__}\refbimodindex{__main__}.
|
---|
118 |
|
---|
119 | The global statement has the same scope as a name binding operation
|
---|
120 | in the same block. If the nearest enclosing scope for a free variable
|
---|
121 | contains a global statement, the free variable is treated as a global.
|
---|
122 |
|
---|
123 | A class definition is an executable statement that may use and define
|
---|
124 | names. These references follow the normal rules for name resolution.
|
---|
125 | The namespace of the class definition becomes the attribute dictionary
|
---|
126 | of the class. Names defined at the class scope are not visible in
|
---|
127 | methods.
|
---|
128 |
|
---|
129 | \subsection{Interaction with dynamic features \label{dynamic-features}}
|
---|
130 |
|
---|
131 | There are several cases where Python statements are illegal when
|
---|
132 | used in conjunction with nested scopes that contain free
|
---|
133 | variables.
|
---|
134 |
|
---|
135 | If a variable is referenced in an enclosing scope, it is illegal
|
---|
136 | to delete the name. An error will be reported at compile time.
|
---|
137 |
|
---|
138 | If the wild card form of import --- \samp{import *} --- is used in a
|
---|
139 | function and the function contains or is a nested block with free
|
---|
140 | variables, the compiler will raise a \exception{SyntaxError}.
|
---|
141 |
|
---|
142 | If \keyword{exec} is used in a function and the function contains or
|
---|
143 | is a nested block with free variables, the compiler will raise a
|
---|
144 | \exception{SyntaxError} unless the exec explicitly specifies the local
|
---|
145 | namespace for the \keyword{exec}. (In other words, \samp{exec obj}
|
---|
146 | would be illegal, but \samp{exec obj in ns} would be legal.)
|
---|
147 |
|
---|
148 | The \function{eval()}, \function{execfile()}, and \function{input()}
|
---|
149 | functions and the \keyword{exec} statement do not have access to the
|
---|
150 | full environment for resolving names. Names may be resolved in the
|
---|
151 | local and global namespaces of the caller. Free variables are not
|
---|
152 | resolved in the nearest enclosing namespace, but in the global
|
---|
153 | namespace.\footnote{This limitation occurs because the code that is
|
---|
154 | executed by these operations is not available at the time the
|
---|
155 | module is compiled.}
|
---|
156 | The \keyword{exec} statement and the \function{eval()} and
|
---|
157 | \function{execfile()} functions have optional arguments to override
|
---|
158 | the global and local namespace. If only one namespace is specified,
|
---|
159 | it is used for both.
|
---|
160 |
|
---|
161 | \section{Exceptions \label{exceptions}}
|
---|
162 | \index{exception}
|
---|
163 |
|
---|
164 | Exceptions are a means of breaking out of the normal flow of control
|
---|
165 | of a code block in order to handle errors or other exceptional
|
---|
166 | conditions. An exception is
|
---|
167 | \emph{raised}\index{raise an exception} at the point where the error
|
---|
168 | is detected; it may be \emph{handled}\index{handle an exception} by
|
---|
169 | the surrounding code block or by any code block that directly or
|
---|
170 | indirectly invoked the code block where the error occurred.
|
---|
171 | \index{exception handler}
|
---|
172 | \index{errors}
|
---|
173 | \index{error handling}
|
---|
174 |
|
---|
175 | The Python interpreter raises an exception when it detects a run-time
|
---|
176 | error (such as division by zero). A Python program can also
|
---|
177 | explicitly raise an exception with the \keyword{raise} statement.
|
---|
178 | Exception handlers are specified with the \keyword{try} ... \keyword{except}
|
---|
179 | statement. The \keyword{try} ... \keyword{finally} statement
|
---|
180 | specifies cleanup code which does not handle the exception, but is
|
---|
181 | executed whether an exception occurred or not in the preceding code.
|
---|
182 |
|
---|
183 | Python uses the ``termination''\index{termination model} model of
|
---|
184 | error handling: an exception handler can find out what happened and
|
---|
185 | continue execution at an outer level, but it cannot repair the cause
|
---|
186 | of the error and retry the failing operation (except by re-entering
|
---|
187 | the offending piece of code from the top).
|
---|
188 |
|
---|
189 | When an exception is not handled at all, the interpreter terminates
|
---|
190 | execution of the program, or returns to its interactive main loop. In
|
---|
191 | either case, it prints a stack backtrace, except when the exception is
|
---|
192 | \exception{SystemExit}\withsubitem{(built-in
|
---|
193 | exception)}{\ttindex{SystemExit}}.
|
---|
194 |
|
---|
195 | Exceptions are identified by class instances. The \keyword{except}
|
---|
196 | clause is selected depending on the class of the instance: it must
|
---|
197 | reference the class of the instance or a base class thereof. The
|
---|
198 | instance can be received by the handler and can carry additional
|
---|
199 | information about the exceptional condition.
|
---|
200 |
|
---|
201 | Exceptions can also be identified by strings, in which case the
|
---|
202 | \keyword{except} clause is selected by object identity. An arbitrary
|
---|
203 | value can be raised along with the identifying string which can be
|
---|
204 | passed to the handler.
|
---|
205 |
|
---|
206 | \deprecated{2.5}{String exceptions should not be used in new code.
|
---|
207 | They will not be supported in a future version of Python. Old code
|
---|
208 | should be rewritten to use class exceptions instead.}
|
---|
209 |
|
---|
210 | \begin{notice}[warning]
|
---|
211 | Messages to exceptions are not part of the Python API. Their contents may
|
---|
212 | change from one version of Python to the next without warning and should not
|
---|
213 | be relied on by code which will run under multiple versions of the
|
---|
214 | interpreter.
|
---|
215 | \end{notice}
|
---|
216 |
|
---|
217 | See also the description of the \keyword{try} statement in
|
---|
218 | section~\ref{try} and \keyword{raise} statement in
|
---|
219 | section~\ref{raise}.
|
---|