1 files changed, 0 insertions, 201 deletions
diff --git a/Doc/ref/ref4.tex b/Doc/ref/ref4.tex
deleted file mode 100644
index 4b4d522..0000000
--- a/Doc/ref/ref4.tex
+++ /dev/null
@@ -1,201 +0,0 @@
-\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 or class instances.  Two
-different string objects with the same value identify different
-exceptions.  An exception can be raised with a class instance.  Such
-exceptions are caught by specifying an except clause that has the
-class name (or a base class) as the condition.
-
-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.  For exceptions raised
-with a class instance, the instance is passed as the ``parameter''.
-
-For example:
-
-\begin{verbatim}
->>> class Error:
-...     def __init__(self, msg): self.msg = msg
-... 
->>> class SpecificError(Error): pass
-... 
->>> try:
-...     raise SpecificError('broken')
-... except Error, obj:
-...     print obj.msg
-... 
-broken
-\end{verbatim}
-
-See also the description of the \verb@try@ and \verb@raise@
-statements.