object's address in memory. An object's {\em type} determines the

operations that an object supports (e.g., ``does it have a length?'')

and also defines the ``meaning'' of the object's value. The type also

Some objects contain references to ``external'' resources such as open

files or windows. It is understood that these resources are freed

when the object is garbage-collected, but since garbage collection is

not guaranteed to happen, such objects also provide an explicit way to

release the external resource, usually a \verb\close\ method.

Programs are strongly recommended to always explicitly close such

objects.

Types affect almost all aspects of an object's life. Even the meaning

of object identity is affected in some sense: for immutable types,

operations that compute new values may actually return a reference to

any existing object with the same type and value, while for mutable

objects this is not allowed. E.g., after

\verb\a\ and \verb\b\ may or may not refer to the same object with the

value one, depending on the implementation, but \verb\c\ and \verb\d\

are guaranteed to refer to two different, unique, newly created empty

lists.

\section{Code blocks, execution frames, and name spaces}

A ``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 block may

textually contain other code blocks. Code blocks may invoke other

code blocks (that aren't textually contained) as part of their

execution.

Each command typed interactively is a separate code block; a script

file is a code block; the string argument passed to the built-in

functions \verb\eval\ and \verb\exec\ are code blocks; 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 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'' that affect execution of the code block.

A 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 ``binding'' a name (to an object); changing the mapping of a

name is called ``rebinding''; removing a name from the name space is

called ``unbinding''. Name spaces are functionally equivalent to

dictionaries (described below).

The ``local name space'' of an execution frame determines the default

place where names are defined and searched. The ``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.

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 does not bind a name.)

When a global name is not found in the global name space, it is

searched in the list of ``built-in'' names (this 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.

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.

\begin{center}

\begin{tabular}{|l|l|l|l|}

Code block type & Global name space & Local name space & Notes \\

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

String passed to \verb\exec\ or \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 & \\

\end{tabular}

\end{center}

Notes:

\begin{description}

\item[(1)] The global and local name space for these functions can be

overridden with optional extra arguments.

\end{description}

\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 ``raised'' at the point where the error

is detected; it may be ``handled'' by the surrounding code block or by any

code block that directly or indirectly invoked the code block where

the error occurred.

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: a 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.

\verb\func_globals\ attribute of functions defined in the module).

class, the argument list must be empty; otherwise, the arguments are

evaluated.

A call always returns some value, possibly \verb\None\, unless it

raises an exception. How this value is computed depends on the type

of the callable object. If it is:

\begin{description}

\item[a user-defined function:] the code block for the function is

executed, passing it the argument list. The first thing the code

block will do is bind the formal parameters to the arguments. When

the code block executes a \verb\return\ statement, this specifies the

return value of the function call.

\item[a built-in function or method:] the result is up to the

interpreter; see the library reference manual for the descriptions of

built-in functions and methods.

\item[a class object:] a new instance of that class is returned.

\item[a class instance method:] the corresponding user-defined

function is called, with an argument list that is one longer than the

argument list of the call: the instance becomes the first argument.

\end{description}

suite, a search for an exception handler is started. This inspects

the except clauses (exception handlers) in turn until one is found

that matches the exception. A condition-less except clause (which

must be last) matches any exception. For except clause with a

condition, that condition is evaluated, and the clause matches the

exception if the resulting object is ``compatible'' with the

exception. An object is compatible with an exception if it is either

the object that identifies the exception or it is a tuple containing

an item that is compatible with the exception.

If no except clause matches the exception, the search for an exception

handler continues in the surrounding code and on the invocation stack.

If the evaluation of a condition in the header of an except clause

raises an exception, the original search for a handler is cancelled

and a search starts for the new exception in the surrounding code and

on the call stack.

When a matching except clause is found in a try statement, the

exception's parameter is assigned to the target specified in the

except clause (if present), and the except clause's suite is executed.

When the end of this suite is reached, execution continues normally

at the point following the entire try statement. (This means that if

two nested handlers exist for the same exception, and the exception

occurs in the try clause of the inner handler, the outer handler will

not notice the exception.)

\verb\finally\ clause is executed. When an exception occurs in the

\verb\try\ suite of a \verb\try...finally\ statement, the

XXX Syntax for interactive input, eval, exec, execfile, input