Guido van Rossum | 46f3e00 | 1992-08-14 09:11:01 +0000 | [diff] [blame] | 1 | \chapter{Execution model} |
| 2 | \index{execution model} |
| 3 | |
| 4 | \section{Code blocks, execution frames, and name spaces} \label{execframes} |
| 5 | \index{code block} |
| 6 | \indexii{execution}{frame} |
| 7 | \index{name space} |
| 8 | |
| 9 | A {\em code block} is a piece of Python program text that can be |
| 10 | executed as a unit, such as a module, a class definition or a function |
| 11 | body. Some code blocks (like modules) are executed only once, others |
| 12 | (like function bodies) may be executed many times. Code block may |
| 13 | textually contain other code blocks. Code blocks may invoke other |
| 14 | code blocks (that may or may not be textually contained in them) as |
| 15 | part of their execution, e.g. by invoking (calling) a function. |
| 16 | \index{code block} |
| 17 | \indexii{code}{block} |
| 18 | |
| 19 | The following are code blocks: A module is a code block. A function |
| 20 | body is a code block. A class definition is a code block. Each |
| 21 | command typed interactively is a separate code block; a script file is |
Guido van Rossum | 4bd023f | 1993-10-27 13:49:20 +0000 | [diff] [blame^] | 22 | a code block. The string argument passed to the built-in function |
| 23 | \verb\eval\ and to the \verb\exec\ statement are code blocks. |
| 24 | And finally, the |
Guido van Rossum | 46f3e00 | 1992-08-14 09:11:01 +0000 | [diff] [blame] | 25 | expression read and evaluated by the built-in function \verb\input\ is |
| 26 | a code block. |
| 27 | |
| 28 | A code block is executed in an execution frame. An {\em execution |
| 29 | frame} contains some administrative information (used for debugging), |
| 30 | determines where and how execution continues after the code block's |
| 31 | execution has completed, and (perhaps most importantly) defines two |
| 32 | name spaces, the local and the global name space, that affect |
| 33 | execution of the code block. |
| 34 | \indexii{execution}{frame} |
| 35 | |
| 36 | A {\em name space} is a mapping from names (identifiers) to objects. |
| 37 | A particular name space may be referenced by more than one execution |
| 38 | frame, and from other places as well. Adding a name to a name space |
| 39 | is called {\em binding} a name (to an object); changing the mapping of |
| 40 | a name is called {\em rebinding}; removing a name is {\em unbinding}. |
| 41 | Name spaces are functionally equivalent to dictionaries. |
| 42 | \index{name space} |
| 43 | \indexii{binding}{name} |
| 44 | \indexii{rebinding}{name} |
| 45 | \indexii{unbinding}{name} |
| 46 | |
| 47 | The {\em local name space} of an execution frame determines the default |
| 48 | place where names are defined and searched. The {\em global name |
| 49 | space} determines the place where names listed in \verb\global\ |
| 50 | statements are defined and searched, and where names that are not |
| 51 | explicitly bound in the current code block are searched. |
| 52 | \indexii{local}{name space} |
| 53 | \indexii{global}{name space} |
| 54 | \stindex{global} |
| 55 | |
| 56 | Whether a name is local or global in a code block is determined by |
| 57 | static inspection of the source text for the code block: in the |
| 58 | absence of \verb\global\ statements, a name that is bound anywhere in |
| 59 | the code block is local in the entire code block; all other names are |
| 60 | considered global. The \verb\global\ statement forces global |
| 61 | interpretation of selected names throughout the code block. The |
| 62 | following constructs bind names: formal parameters, \verb\import\ |
| 63 | statements, class and function definitions (these bind the class or |
| 64 | function name), and targets that are identifiers if occurring in an |
| 65 | assignment, \verb\for\ loop header, or \verb\except\ clause header. |
| 66 | (A target occurring in a \verb\del\ statement does not bind a name.) |
| 67 | |
| 68 | When a global name is not found in the global name space, it is |
| 69 | searched in the list of ``built-in'' names (which is actually the |
Guido van Rossum | 4bd023f | 1993-10-27 13:49:20 +0000 | [diff] [blame^] | 70 | global name space of the module \verb\__builtin__\). When a name is not |
Guido van Rossum | 46f3e00 | 1992-08-14 09:11:01 +0000 | [diff] [blame] | 71 | found at all, the \verb\NameError\ exception is raised. |
| 72 | |
| 73 | The following table lists the meaning of the local and global name |
| 74 | space for various types of code blocks. The name space for a |
| 75 | particular module is automatically created when the module is first |
| 76 | referenced. |
| 77 | |
| 78 | \begin{center} |
| 79 | \begin{tabular}{|l|l|l|l|} |
| 80 | \hline |
| 81 | Code block type & Global name space & Local name space & Notes \\ |
| 82 | \hline |
| 83 | Module & n.s. for this module & same as global & \\ |
| 84 | Script & n.s. for \verb\__main__\ & same as global & \\ |
| 85 | Interactive command & n.s. for \verb\__main__\ & same as global & \\ |
| 86 | Class definition & global n.s. of containing block & new n.s. & \\ |
| 87 | Function body & global n.s. of containing block & new n.s. & \\ |
| 88 | String passed to \verb\exec\ or \verb\eval\ |
| 89 | & global n.s. of caller & local n.s. of caller & (1) \\ |
| 90 | File read by \verb\execfile\ |
| 91 | & global n.s. of caller & local n.s. of caller & (1) \\ |
| 92 | Expression read by \verb\input\ |
| 93 | & global n.s. of caller & local n.s. of caller & \\ |
| 94 | \hline |
| 95 | \end{tabular} |
| 96 | \end{center} |
| 97 | |
| 98 | Notes: |
| 99 | |
| 100 | \begin{description} |
| 101 | |
| 102 | \item[n.s.] means {\em name space} |
| 103 | |
| 104 | \item[(1)] The global and local name space for these functions can be |
| 105 | overridden with optional extra arguments. |
| 106 | |
| 107 | \end{description} |
| 108 | |
| 109 | \section{Exceptions} |
| 110 | |
| 111 | Exceptions are a means of breaking out of the normal flow of control |
| 112 | of a code block in order to handle errors or other exceptional |
| 113 | conditions. An exception is {\em raised} at the point where the error |
| 114 | is detected; it may be {\em handled} by the surrounding code block or |
| 115 | by any code block that directly or indirectly invoked the code block |
| 116 | where the error occurred. |
| 117 | \index{exception} |
| 118 | \index{raise an exception} |
| 119 | \index{handle an exception} |
| 120 | \index{exception handler} |
| 121 | \index{errors} |
| 122 | \index{error handling} |
| 123 | |
| 124 | The Python interpreter raises an exception when it detects an run-time |
| 125 | error (such as division by zero). A Python program can also |
| 126 | explicitly raise an exception with the \verb\raise\ statement. |
| 127 | Exception handlers are specified with the \verb\try...except\ |
| 128 | statement. |
| 129 | |
| 130 | Python uses the ``termination'' model of error handling: an exception |
| 131 | handler can find out what happened and continue execution at an outer |
| 132 | level, but it cannot repair the cause of the error and retry the |
| 133 | failing operation (except by re-entering the the offending piece of |
| 134 | code from the top). |
| 135 | |
| 136 | When an exception is not handled at all, the interpreter terminates |
| 137 | execution of the program, or returns to its interactive main loop. |
| 138 | |
| 139 | Exceptions are identified by string objects. Two different string |
| 140 | objects with the same value identify different exceptions. |
| 141 | |
| 142 | When an exception is raised, an object (maybe \verb\None\) is passed |
| 143 | as the exception's ``parameter''; this object does not affect the |
| 144 | selection of an exception handler, but is passed to the selected |
| 145 | exception handler as additional information. |
| 146 | |
| 147 | See also the description of the \verb\try\ and \verb\raise\ |
| 148 | statements. |