\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 blocks 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 {\tt exec} statements or the construct {\tt from \ldots import *}, the semantics of names not explicitly mentioned in a {\tt global} statement change subtly: name lookup first searches the local name space, then the global one, then the built-in one.} \bimodindex{__builtin__} \stindex{from} \stindex{exec} \stindex{global} \ttindex{NameError} 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} \bimodindex{__main__} 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} The built-in function \verb@vars()@ returns a dictionary representing the current local name space. The effect of modifications to this dictionary on the name space are undefined.% \footnote{The current implementation returns the dictionary actually used to implement the name space, {\em except} for functions, where the optimizer may cause the local name space to be implemented differently.} \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.