cpython/Doc/ref/ref4.tex

\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. & (2) \\
String passed to \verb@exec@ statement
	& global n.s. of containing 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.

\item[(2)] The body of lambda forms (see section \ref{lambda}) is
treated exactly the same as a (nested) function definition.  Lambda
forms have their own name space consisting of their formal arguments.
\indexii{lambda}{form}

\end{description}

The built-in functions \verb@globals()@ and \verb@locals()@ returns a
dictionary representing the current global and local name space,
respectively.  The effect of modifications to this dictionary on the
name space are undefined.%
\footnote{The current implementations return 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, and \verb@locals()@ returns a read-only dictionary.}

\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.