1998-07-24 19:12:32 -03:00
|
|
|
\chapter{Execution model\label{execmodel}}
|
1998-05-06 16:52:49 -03:00
|
|
|
\index{execution model}
|
|
|
|
|
1998-07-28 16:34:22 -03:00
|
|
|
\section{Code blocks, execution frames, and namespaces\label{execframes}}
|
1998-05-06 16:52:49 -03:00
|
|
|
\index{code block}
|
|
|
|
\indexii{execution}{frame}
|
1998-07-23 16:36:00 -03:00
|
|
|
\index{namespace}
|
1998-05-06 16:52:49 -03:00
|
|
|
|
1998-07-24 19:12:32 -03:00
|
|
|
A \dfn{code block} is a piece of Python program text that can be
|
1998-05-06 16:52:49 -03:00
|
|
|
executed as a unit, such as a module, a class definition or a function
|
1998-07-23 16:36:00 -03:00
|
|
|
body. Some code blocks (like modules) are normally executed only once, others
|
1998-05-06 16:52:49 -03:00
|
|
|
(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
|
1998-07-24 12:36:43 -03:00
|
|
|
part of their execution, e.g., by invoking (calling) a function.
|
1998-05-06 16:52:49 -03:00
|
|
|
\index{code block}
|
|
|
|
\indexii{code}{block}
|
|
|
|
|
1998-07-23 16:36:00 -03:00
|
|
|
The following are code blocks: A module is a code block. A function
|
1998-05-06 16:52:49 -03:00
|
|
|
body is a code block. A class definition is a code block. Each
|
1998-07-23 16:36:00 -03: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
|
|
|
|
`\code{-c}' option) is a code block. The file read by the built-in
|
|
|
|
function \function{execfile()} is a code block. The string argument
|
|
|
|
passed to the built-in function \function{eval()} and to the
|
|
|
|
\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 16:52:49 -03:00
|
|
|
|
1998-07-24 19:12:32 -03:00
|
|
|
A code block is executed in an execution frame. An \dfn{execution
|
1998-05-06 16:52:49 -03:00
|
|
|
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
|
1998-07-23 16:36:00 -03:00
|
|
|
namespaces, the local and the global namespace, that affect
|
1998-05-06 16:52:49 -03:00
|
|
|
execution of the code block.
|
|
|
|
\indexii{execution}{frame}
|
|
|
|
|
1998-07-24 19:12:32 -03:00
|
|
|
A \dfn{namespace} is a mapping from names (identifiers) to objects.
|
1998-07-23 16:36:00 -03:00
|
|
|
A particular namespace may be referenced by more than one execution
|
|
|
|
frame, and from other places as well. Adding a name to a namespace
|
1998-07-24 19:12:32 -03:00
|
|
|
is called \dfn{binding} a name (to an object); changing the mapping of
|
|
|
|
a name is called \dfn{rebinding}; removing a name is \dfn{unbinding}.
|
1998-07-23 16:36:00 -03:00
|
|
|
Namespaces are functionally equivalent to dictionaries (and often
|
|
|
|
implemented as dictionaries).
|
|
|
|
\index{namespace}
|
1998-05-06 16:52:49 -03:00
|
|
|
\indexii{binding}{name}
|
|
|
|
\indexii{rebinding}{name}
|
|
|
|
\indexii{unbinding}{name}
|
|
|
|
|
1998-07-24 19:12:32 -03:00
|
|
|
The \dfn{local namespace} of an execution frame determines the default
|
|
|
|
place where names are defined and searched. The \dfn{global
|
1998-07-23 16:36:00 -03:00
|
|
|
namespace} determines the place where names listed in \keyword{global}
|
1998-05-06 16:52:49 -03:00
|
|
|
statements are defined and searched, and where names that are not
|
1998-07-23 16:36:00 -03:00
|
|
|
bound anywhere in the current code block are searched.
|
|
|
|
\indexii{local}{namespace}
|
|
|
|
\indexii{global}{namespace}
|
1998-05-06 16:52:49 -03:00
|
|
|
\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
|
1998-07-23 16:36:00 -03: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
|
1998-05-06 16:52:49 -03:00
|
|
|
interpretation of selected names throughout the code block. The
|
1998-07-23 16:36:00 -03:00
|
|
|
following constructs bind names: formal parameters to functions,
|
|
|
|
\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
|
|
|
|
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 16:52:49 -03:00
|
|
|
|
|
|
|
A target occurring in a \keyword{del} statement is also considered bound
|
|
|
|
for this purpose (though the actual semantics are to ``unbind'' the
|
|
|
|
name).
|
|
|
|
|
1998-07-23 16:36:00 -03: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
|
|
|
|
namespace of the module \module{__builtin__}). The built-in namespace
|
|
|
|
associated with the execution of a code block is actually found by
|
|
|
|
looking up the name \code{__builtins__} is its global 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 mode is in effect. When a name is
|
|
|
|
not found at all, a \exception{NameError} exception is raised.%
|
1998-05-06 16:52:49 -03:00
|
|
|
\refbimodindex{__builtin__}
|
|
|
|
\stindex{from}
|
|
|
|
\stindex{exec}
|
|
|
|
\stindex{global}
|
1998-07-23 16:36:00 -03:00
|
|
|
\indexii{restricted}{execution}
|
1998-05-06 16:52:49 -03:00
|
|
|
\withsubitem{(built-in exception)}{\ttindex{NameError}}
|
|
|
|
|
1998-07-23 16:36:00 -03:00
|
|
|
The following table lists the meaning of the local and global
|
|
|
|
namespace for various types of code blocks. The namespace for a
|
1998-05-06 16:52:49 -03:00
|
|
|
particular module is automatically created when the module is first
|
1998-07-23 16:36:00 -03:00
|
|
|
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!
|
1998-05-06 16:52:49 -03:00
|
|
|
|
1998-10-20 21:26:56 -03:00
|
|
|
\begin{tableiv}{l|l|l|l}{textrm}
|
1998-07-24 19:12:32 -03:00
|
|
|
{Code block type}{Global namespace}{Local namespace}{Notes}
|
1998-10-20 21:26:56 -03:00
|
|
|
\lineiv{Module}
|
|
|
|
{n.s. for this module}
|
1998-07-24 19:12:32 -03:00
|
|
|
{same as global}{}
|
1998-10-20 21:26:56 -03:00
|
|
|
\lineiv{Script (file or command)}
|
|
|
|
{n.s. for \module{__main__}}
|
1998-07-24 19:12:32 -03:00
|
|
|
{same as global}{(1)}
|
1998-10-20 21:26:56 -03:00
|
|
|
\lineiv{Interactive command}
|
|
|
|
{n.s. for \module{__main__}}
|
1998-07-24 19:12:32 -03:00
|
|
|
{same as global}{}
|
1998-10-20 21:26:56 -03:00
|
|
|
\lineiv{Class definition}
|
|
|
|
{global n.s. of containing block}
|
1998-07-24 19:12:32 -03:00
|
|
|
{new n.s.}{}
|
1998-10-20 21:26:56 -03:00
|
|
|
\lineiv{Function body}
|
|
|
|
{global n.s. of containing block}
|
1998-07-24 19:12:32 -03:00
|
|
|
{new n.s.}{(2)}
|
1998-10-20 21:26:56 -03:00
|
|
|
\lineiv{String passed to \keyword{exec} statement}
|
|
|
|
{global n.s. of containing block}
|
1998-07-24 19:12:32 -03:00
|
|
|
{local n.s. of containing block}{(2), (3)}
|
1998-10-20 21:26:56 -03:00
|
|
|
\lineiv{String passed to \function{eval()}}
|
|
|
|
{global n.s. of caller}
|
1998-07-24 19:12:32 -03:00
|
|
|
{local n.s. of caller}{(2), (3)}
|
1998-10-20 21:26:56 -03:00
|
|
|
\lineiv{File read by \function{execfile()}}
|
|
|
|
{global n.s. of caller}
|
1998-07-24 19:12:32 -03:00
|
|
|
{local n.s. of caller}{(2), (3)}
|
1998-10-20 21:26:56 -03:00
|
|
|
\lineiv{Expression read by \function{input()}}
|
|
|
|
{global n.s. of caller}
|
1998-07-24 19:12:32 -03:00
|
|
|
{local n.s. of caller}{}
|
|
|
|
\end{tableiv}
|
1998-05-06 16:52:49 -03:00
|
|
|
\refbimodindex{__main__}
|
|
|
|
|
|
|
|
Notes:
|
|
|
|
|
|
|
|
\begin{description}
|
|
|
|
|
1998-07-24 19:12:32 -03:00
|
|
|
\item[n.s.] means \emph{namespace}
|
1998-05-06 16:52:49 -03:00
|
|
|
|
1998-07-23 16:36:00 -03:00
|
|
|
\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
|
1998-05-06 16:52:49 -03:00
|
|
|
overridden with optional extra arguments.
|
|
|
|
|
1998-07-23 16:36:00 -03:00
|
|
|
\item[(3)] The \keyword{exec} statement and the \function{eval()} and
|
|
|
|
\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 16:52:49 -03:00
|
|
|
|
|
|
|
\end{description}
|
|
|
|
|
|
|
|
The built-in functions \function{globals()} and \function{locals()} returns a
|
1998-07-23 16:36:00 -03:00
|
|
|
dictionary representing the current global and local namespace,
|
1998-05-06 16:52:49 -03:00
|
|
|
respectively. The effect of modifications to this dictionary on the
|
1998-07-23 16:36:00 -03:00
|
|
|
namespace are undefined.%
|
1998-05-06 16:52:49 -03:00
|
|
|
\footnote{The current implementations return the dictionary actually
|
1998-07-24 19:12:32 -03:00
|
|
|
used to implement the namespace, \emph{except} for functions, where
|
1998-07-23 16:36:00 -03:00
|
|
|
the optimizer may cause the local namespace to be implemented
|
1998-05-06 16:52:49 -03:00
|
|
|
differently, and \function{locals()} returns a read-only dictionary.}
|
|
|
|
|
1998-07-28 16:34:22 -03:00
|
|
|
\section{Exceptions\label{exceptions}}
|
1998-05-06 16:52:49 -03: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
|
1998-07-24 19:12:32 -03:00
|
|
|
conditions. An exception is \emph{raised} at the point where the error
|
|
|
|
is detected; it may be \emph{handled} by the surrounding code block or
|
1998-05-06 16:52:49 -03:00
|
|
|
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}
|
|
|
|
|
1998-07-23 16:36:00 -03:00
|
|
|
The Python interpreter raises an exception when it detects a run-time
|
1998-05-06 16:52:49 -03: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 16:36:00 -03: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 16:52:49 -03:00
|
|
|
|
|
|
|
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
|
1998-07-23 16:36:00 -03:00
|
|
|
failing operation (except by re-entering the offending piece of
|
1998-05-06 16:52:49 -03:00
|
|
|
code from the top).
|
|
|
|
|
|
|
|
When an exception is not handled at all, the interpreter terminates
|
1998-07-23 16:36:00 -03: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
|
|
|
|
\exception{SystemExit}.\ttindex{SystemExit}
|
|
|
|
|
|
|
|
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 16:52:49 -03:00
|
|
|
|
|
|
|
When an exception is raised, an object (maybe \code{None}) is passed
|
1998-07-23 16:36:00 -03: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 16:52:49 -03:00
|
|
|
|
|
|
|
See also the description of the \keyword{try} and \keyword{raise}
|
1998-07-23 16:36:00 -03:00
|
|
|
statements in chapter 7.
|