| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | \chapter{Execution model \label{execmodel}} | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | \index{execution model} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | \section{Code blocks, execution frames, and namespaces \label{execframes}} | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | \index{code block} | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | \index{namespace} | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | \indexii{execution}{frame} | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | A \dfn{code block}\indexii{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 normally 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. | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | The following are code blocks: A module is a code block.  A function | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | body is a code block.  A class definition is a code block.  Each | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | command typed interactively is a separate code block; a script file (a | 
					
						
							|  |  |  | file given as standard input to the interpreter or specified on the | 
					
						
							|  |  |  | interpreter command line the first argument) is a code block; a script | 
					
						
							|  |  |  | command (a command specified on the interpreter command line with the | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | `\strong{-c}' option) is a code block.  The file read by the built-in | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | function \function{execfile()} is a code block.  The string argument | 
					
						
							|  |  |  | passed to the built-in function \function{eval()} and to the | 
					
						
							| 
									
										
										
										
											2001-03-23 14:05:16 +00:00
										 |  |  | \keyword{exec} statement is a code block.  And finally, the expression | 
					
						
							|  |  |  | read and evaluated by the built-in function \function{input()} is a | 
					
						
							|  |  |  | code block. | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											1998-07-24 22:12:32 +00:00
										 |  |  | A code block is executed in an execution frame.  An \dfn{execution | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | frame}\indexii{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 | 
					
						
							| 
									
										
										
										
											2001-03-23 14:05:16 +00:00
										 |  |  | most importantly) defines two namespaces, the local and the global | 
					
						
							|  |  |  | namespace, that affect execution of the code block. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | A \dfn{namespace}\index{namespace} is a mapping from names | 
					
						
							|  |  |  | (identifiers) to objects.  A particular namespace may be referenced by | 
					
						
							|  |  |  | more than one execution frame, and from other places as well.  Adding | 
					
						
							|  |  |  | a name to a namespace is called \dfn{binding}\indexii{binding}{name} a | 
					
						
							|  |  |  | name (to an object); changing the mapping of a name is called | 
					
						
							|  |  |  | \dfn{rebinding}\indexii{rebinding}{name}; removing a name is | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | \dfn{unbinding}\indexii{unbinding}{name}.  Namespaces are functionally | 
					
						
							|  |  |  | equivalent to dictionaries (and often implemented as dictionaries). | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2001-03-23 14:05:16 +00:00
										 |  |  | The \dfn{local namespace}\indexii{local}{namespace} of an execution | 
					
						
							|  |  |  | frame determines the default place where names are defined and | 
					
						
							|  |  |  | searched.  The | 
					
						
							|  |  |  | \dfn{global namespace}\indexii{global}{namespace} determines the place | 
					
						
							|  |  |  | where names listed in \keyword{global}\stindex{global} statements are | 
					
						
							|  |  |  | defined and searched, and where names that are not bound anywhere in | 
					
						
							|  |  |  | the current code block are searched. | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | 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 | 
					
						
							| 
									
										
										
										
											2001-03-23 14:05:16 +00:00
										 |  |  | absence of \keyword{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 \keyword{global} statement forces global | 
					
						
							|  |  |  | interpretation of selected names throughout the code block.  The | 
					
						
							|  |  |  | following constructs bind names: formal parameters to functions, | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | \keyword{import} statements, class and function definitions (these | 
					
						
							|  |  |  | bind the class or function name in the defining block), and targets | 
					
						
							|  |  |  | that are identifiers if occurring in an assignment, \keyword{for} loop | 
					
						
							|  |  |  | header, or in the second position of an \keyword{except} clause | 
					
						
							| 
									
										
										
										
											2001-03-23 14:05:16 +00:00
										 |  |  | header.  Local names are searched only on the local namespace; global | 
					
						
							|  |  |  | names are searched only in the global and built-in | 
					
						
							|  |  |  | namespace.\footnote{ | 
					
						
							|  |  |  |   If the code block contains \keyword{exec} statements or the | 
					
						
							|  |  |  |   construct ``\samp{from \ldots import *}'', the semantics of local | 
					
						
							|  |  |  |   names change: local name lookup first searches the local namespace, | 
					
						
							|  |  |  |   then the global namespace and the built-in namespace.} | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | A target occurring in a \keyword{del} statement is also considered bound | 
					
						
							| 
									
										
										
										
											2001-03-23 14:05:16 +00:00
										 |  |  | for this purpose (though the actual semantics are to ``unbind'' the | 
					
						
							|  |  |  | name). | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | When a global name is not found in the global namespace, it is | 
					
						
							|  |  |  | searched in the built-in namespace (which is actually the global | 
					
						
							| 
									
										
										
										
											2001-03-23 14:05:16 +00:00
										 |  |  | namespace of the module | 
					
						
							|  |  |  | \module{__builtin__}\refbimodindex{__builtin__}).  The built-in | 
					
						
							|  |  |  | namespace associated with the execution of a code block is actually | 
					
						
							| 
									
										
										
										
											2001-05-29 15:44:27 +00:00
										 |  |  | found by looking up the name \code{__builtins__} in its global | 
					
						
							| 
									
										
										
										
											2001-03-23 14:05:16 +00:00
										 |  |  | namespace; this should be a dictionary or a module (in the latter case | 
					
						
							|  |  |  | its dictionary is used).  Normally, the \code{__builtins__} namespace | 
					
						
							|  |  |  | is the dictionary of the built-in module \module{__builtin__} (note: | 
					
						
							|  |  |  | no `s'); if it isn't, restricted | 
					
						
							|  |  |  | execution\indexii{restricted}{execution} mode is in effect.  When a  | 
					
						
							|  |  |  | name is not found at all, a | 
					
						
							|  |  |  | \exception{NameError}\withsubitem{(built-in | 
					
						
							|  |  |  | exception)}{\ttindex{NameError}} exception is raised. | 
					
						
							|  |  |  | \stindex{from} | 
					
						
							|  |  |  | \stindex{exec} | 
					
						
							|  |  |  | \stindex{global} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The following table lists the meaning of the local and global | 
					
						
							|  |  |  | namespace for various types of code blocks.  The namespace for a | 
					
						
							|  |  |  | particular module is automatically created when the module is first | 
					
						
							|  |  |  | imported (i.e., when it is loaded).  Note that in almost all cases, | 
					
						
							|  |  |  | the global namespace is the namespace of the containing module --- | 
					
						
							|  |  |  | scopes in Python do not nest! | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | \begin{tableiv}{l|l|l|l}{textrm} | 
					
						
							|  |  |  |   {Code block type}{Global namespace}{Local namespace}{Notes} | 
					
						
							|  |  |  |   \lineiv{Module} | 
					
						
							|  |  |  |          {n.s. for this module} | 
					
						
							|  |  |  |          {same as global}{} | 
					
						
							|  |  |  |   \lineiv{Script (file or command)} | 
					
						
							|  |  |  |          {n.s. for \module{__main__}\refbimodindex{__main__}} | 
					
						
							|  |  |  |          {same as global}{(1)} | 
					
						
							|  |  |  |   \lineiv{Interactive command} | 
					
						
							|  |  |  |          {n.s. for \module{__main__}\refbimodindex{__main__}} | 
					
						
							|  |  |  |          {same as global}{} | 
					
						
							|  |  |  |   \lineiv{Class definition} | 
					
						
							|  |  |  |          {global n.s. of containing block} | 
					
						
							|  |  |  |          {new n.s.}{} | 
					
						
							|  |  |  |   \lineiv{Function body} | 
					
						
							|  |  |  |          {global n.s. of containing block} | 
					
						
							|  |  |  |          {new n.s.}{(2)} | 
					
						
							|  |  |  |   \lineiv{String passed to \keyword{exec} statement} | 
					
						
							|  |  |  |          {global n.s. of containing block} | 
					
						
							|  |  |  |          {local n.s. of containing block}{(2), (3)} | 
					
						
							|  |  |  |   \lineiv{String passed to \function{eval()}} | 
					
						
							|  |  |  |          {global n.s. of caller} | 
					
						
							|  |  |  |          {local n.s. of caller}{(2), (3)} | 
					
						
							|  |  |  |   \lineiv{File read by \function{execfile()}} | 
					
						
							|  |  |  |          {global n.s. of caller} | 
					
						
							|  |  |  |          {local n.s. of caller}{(2), (3)} | 
					
						
							|  |  |  |   \lineiv{Expression read by \function{input()}} | 
					
						
							|  |  |  |          {global n.s. of caller} | 
					
						
							|  |  |  |          {local n.s. of caller}{} | 
					
						
							|  |  |  | \end{tableiv} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Notes: | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | \begin{description} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | \item[n.s.] means \emph{namespace} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | \item[(1)] The main module for a script is always called | 
					
						
							|  |  |  | \module{__main__}; ``the filename don't enter into it.'' | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | \item[(2)] The global and local namespace for these can be | 
					
						
							|  |  |  | overridden with optional extra arguments. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | \item[(3)] The \keyword{exec} statement and the \function{eval()} and | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | \function{execfile()} functions have optional arguments to override | 
					
						
							|  |  |  | the global and local namespace.  If only one namespace is specified, | 
					
						
							|  |  |  | it is used for both. | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2001-03-23 14:05:16 +00:00
										 |  |  | \end{description} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The built-in functions \function{globals()} and \function{locals()} returns a | 
					
						
							|  |  |  | dictionary representing the current global and local namespace, | 
					
						
							|  |  |  | respectively.  The effect of modifications to this dictionary on the | 
					
						
							|  |  |  | namespace are undefined.\footnote{ | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  |   The current implementations return the dictionary actually used to | 
					
						
							|  |  |  |   implement the namespace, \emph{except} for functions, where the | 
					
						
							|  |  |  |   optimizer may cause the local namespace to be implemented | 
					
						
							|  |  |  |   differently, and \function{locals()} returns a read-only | 
					
						
							|  |  |  |   dictionary.} | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | \section{Exceptions \label{exceptions}} | 
					
						
							|  |  |  | \index{exception} | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | 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 | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | conditions.  An exception is | 
					
						
							|  |  |  | \emph{raised}\index{raise an exception} at the point where the error | 
					
						
							|  |  |  | is detected; it may be \emph{handled}\index{handle an exception} by | 
					
						
							|  |  |  | the surrounding code block or by any code block that directly or | 
					
						
							|  |  |  | indirectly invoked the code block where the error occurred. | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | \index{exception handler} | 
					
						
							|  |  |  | \index{errors} | 
					
						
							|  |  |  | \index{error handling} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | The Python interpreter raises an exception when it detects a run-time | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | error (such as division by zero).  A Python program can also | 
					
						
							|  |  |  | explicitly raise an exception with the \keyword{raise} statement. | 
					
						
							|  |  |  | Exception handlers are specified with the \keyword{try} ... \keyword{except} | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | statement.  The \keyword{try} ... \keyword{finally} statement | 
					
						
							|  |  |  | specifies cleanup code which does not handle the exception, but is | 
					
						
							|  |  |  | executed whether an exception occurred or not in the preceding code. | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-04-03 04:51:13 +00:00
										 |  |  | Python uses the ``termination'' \index{termination model}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 offending piece of code from the top). | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | When an exception is not handled at all, the interpreter terminates | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | execution of the program, or returns to its interactive main loop.  In | 
					
						
							|  |  |  | either case, it prints a stack backtrace, except when the exception is  | 
					
						
							| 
									
										
										
										
											1999-05-13 18:38:11 +00:00
										 |  |  | \exception{SystemExit}\withsubitem{(built-in | 
					
						
							|  |  |  | exception)}{\ttindex{SystemExit}}. | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | Exceptions are identified by string objects or class instances. | 
					
						
							|  |  |  | Selection of a matching except clause is based on object identity | 
					
						
							|  |  |  | (i.e., two different string objects with the same value represent | 
					
						
							|  |  |  | different exceptions!)  For string exceptions, the \keyword{except} | 
					
						
							|  |  |  | clause must reference the same string object.  For class exceptions, | 
					
						
							|  |  |  | the \keyword{except} clause must reference the same class or a base | 
					
						
							|  |  |  | class of it. | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | When an exception is raised, an object (maybe \code{None}) is passed | 
					
						
							| 
									
										
										
										
											1998-07-23 19:36:00 +00:00
										 |  |  | as the exception's ``parameter'' or ``value''; this object does not | 
					
						
							|  |  |  | affect the selection of an exception handler, but is passed to the | 
					
						
							|  |  |  | selected exception handler as additional information.  For class | 
					
						
							|  |  |  | exceptions, this object must be an instance of the exception class | 
					
						
							|  |  |  | being raised. | 
					
						
							| 
									
										
										
										
											1998-05-06 19:52:49 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-04-03 04:51:13 +00:00
										 |  |  | See also the description of the \keyword{try} statement in section | 
					
						
							|  |  |  | \ref{try} and \keyword{raise} statement in section \ref{raise}. |