| \chapter{Execution model} |
| \index{execution model} |
| |
| \section{Code blocks, execution frames, and name spaces} \label{execframes} |
| \index{code block} |
| \indexii{execution}{frame} |
| \index{name space} |
| |
| A {\em code block} is a piece of Python program text that can be |
| executed as a unit, such as a module, a class definition or a function |
| body. Some code blocks (like modules) are executed only once, others |
| (like function bodies) may be executed many times. Code block may |
| textually contain other code blocks. Code blocks may invoke other |
| code blocks (that may or may not be textually contained in them) as |
| part of their execution, e.g. by invoking (calling) a function. |
| \index{code block} |
| \indexii{code}{block} |
| |
| The following are code blocks: A module is a code block. A function |
| body is a code block. A class definition is a code block. Each |
| command typed interactively is a separate code block; a script file is |
| a code block. The string argument passed to the built-in function |
| \verb@eval@ and to the \verb@exec@ statement are code blocks. |
| And finally, the |
| expression read and evaluated by the built-in function \verb@input@ is |
| a code block. |
| |
| A code block is executed in an execution frame. An {\em execution |
| frame} contains some administrative information (used for debugging), |
| determines where and how execution continues after the code block's |
| execution has completed, and (perhaps most importantly) defines two |
| name spaces, the local and the global name space, that affect |
| execution of the code block. |
| \indexii{execution}{frame} |
| |
| A {\em name space} is a mapping from names (identifiers) to objects. |
| A particular name space may be referenced by more than one execution |
| frame, and from other places as well. Adding a name to a name space |
| is called {\em binding} a name (to an object); changing the mapping of |
| a name is called {\em rebinding}; removing a name is {\em unbinding}. |
| Name spaces are functionally equivalent to dictionaries. |
| \index{name space} |
| \indexii{binding}{name} |
| \indexii{rebinding}{name} |
| \indexii{unbinding}{name} |
| |
| The {\em local name space} of an execution frame determines the default |
| place where names are defined and searched. The {\em global name |
| space} determines the place where names listed in \verb@global@ |
| statements are defined and searched, and where names that are not |
| explicitly bound in the current code block are searched. |
| \indexii{local}{name space} |
| \indexii{global}{name space} |
| \stindex{global} |
| |
| Whether a name is local or global in a code block is determined by |
| static inspection of the source text for the code block: in the |
| absence of \verb@global@ statements, a name that is bound anywhere in |
| the code block is local in the entire code block; all other names are |
| considered global. The \verb@global@ statement forces global |
| interpretation of selected names throughout the code block. The |
| following constructs bind names: formal parameters, \verb@import@ |
| statements, class and function definitions (these bind the class or |
| function name), and targets that are identifiers if occurring in an |
| assignment, \verb@for@ loop header, or \verb@except@ clause header. |
| |
| A target occurring in a \verb@del@ statement is also considered bound |
| for this purpose (though the actual semantics are to ``unbind'' the |
| name). |
| |
| When a global name is not found in the global name space, it is |
| searched in the list of ``built-in'' names (which is actually the |
| global name space of the module \verb@__builtin__@). When a name is not |
| found at all, the \verb@NameError@ exception is raised.% |
| \footnote{If the code block contains \verb@exec@ statement or the |
| construct \verb@from ... import *@, the semantics of names not |
| explicitly mentioned in a \verb@global@ statement change subtly: name |
| lookup first searches the local name space, then the global one, then |
| the built-in one.} |
| |
| The following table lists the meaning of the local and global name |
| space for various types of code blocks. The name space for a |
| particular module is automatically created when the module is first |
| referenced. Note that in almost all cases, the global name space is |
| the name space of the containing module -- scopes in Python do not |
| nest! |
| |
| \begin{center} |
| \begin{tabular}{|l|l|l|l|} |
| \hline |
| Code block type & Global name space & Local name space & Notes \\ |
| \hline |
| Module & n.s. for this module & same as global & \\ |
| Script & n.s. for \verb@__main__@ & same as global & \\ |
| Interactive command & n.s. for \verb@__main__@ & same as global & \\ |
| Class definition & global n.s. of containing block & new n.s. & \\ |
| Function body & global n.s. of containing block & new n.s. & \\ |
| String passed to \verb@exec@ statement |
| & global n.s. of cobtaining block |
| & local n.s. of containing block & (1) \\ |
| String passed to \verb@eval()@ |
| & global n.s. of caller & local n.s. of caller & (1) \\ |
| File read by \verb@execfile()@ |
| & global n.s. of caller & local n.s. of caller & (1) \\ |
| Expression read by \verb@input@ |
| & global n.s. of caller & local n.s. of caller & \\ |
| \hline |
| \end{tabular} |
| \end{center} |
| |
| Notes: |
| |
| \begin{description} |
| |
| \item[n.s.] means {\em name space} |
| |
| \item[(1)] The global and local name space for these can be |
| overridden with optional extra arguments. |
| |
| \end{description} |
| |
| \section{Exceptions} |
| |
| 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 {\em raised} at the point where the error |
| is detected; it may be {\em handled} by the surrounding code block or |
| by any code block that directly or indirectly invoked the code block |
| where the error occurred. |
| \index{exception} |
| \index{raise an exception} |
| \index{handle an exception} |
| \index{exception handler} |
| \index{errors} |
| \index{error handling} |
| |
| The Python interpreter raises an exception when it detects an run-time |
| error (such as division by zero). A Python program can also |
| explicitly raise an exception with the \verb@raise@ statement. |
| Exception handlers are specified with the \verb@try...except@ |
| statement. |
| |
| 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 the offending piece of |
| code from the top). |
| |
| When an exception is not handled at all, the interpreter terminates |
| execution of the program, or returns to its interactive main loop. |
| |
| Exceptions are identified by string objects. Two different string |
| objects with the same value identify different exceptions. |
| |
| When an exception is raised, an object (maybe \verb@None@) is passed |
| as the exception's ``parameter''; this object does not affect the |
| selection of an exception handler, but is passed to the selected |
| exception handler as additional information. |
| |
| See also the description of the \verb@try@ and \verb@raise@ |
| statements. |