824 lines
32 KiB
TeX
824 lines
32 KiB
TeX
\chapter{Simple statements \label{simple}}
|
|
\indexii{simple}{statement}
|
|
|
|
Simple statements are comprised within a single logical line.
|
|
Several simple statements may occur on a single line separated
|
|
by semicolons. The syntax for simple statements is:
|
|
|
|
\begin{productionlist}
|
|
\production{simple_stmt}{\token{expression_stmt}}
|
|
\productioncont{| \token{assert_stmt}}
|
|
\productioncont{| \token{assignment_stmt}}
|
|
\productioncont{| \token{augmented_assignment_stmt}}
|
|
\productioncont{| \token{pass_stmt}}
|
|
\productioncont{| \token{del_stmt}}
|
|
\productioncont{| \token{print_stmt}}
|
|
\productioncont{| \token{return_stmt}}
|
|
\productioncont{| \token{yield_stmt}}
|
|
\productioncont{| \token{raise_stmt}}
|
|
\productioncont{| \token{break_stmt}}
|
|
\productioncont{| \token{continue_stmt}}
|
|
\productioncont{| \token{import_stmt}}
|
|
\productioncont{| \token{global_stmt}}
|
|
\productioncont{| \token{exec_stmt}}
|
|
\end{productionlist}
|
|
|
|
|
|
\section{Expression statements \label{exprstmts}}
|
|
\indexii{expression}{statement}
|
|
|
|
Expression statements are used (mostly interactively) to compute and
|
|
write a value, or (usually) to call a procedure (a function that
|
|
returns no meaningful result; in Python, procedures return the value
|
|
\code{None}). Other uses of expression statements are allowed and
|
|
occasionally useful. The syntax for an expression statement is:
|
|
|
|
\begin{productionlist}
|
|
\production{expression_stmt}
|
|
{\token{expression_list}}
|
|
\end{productionlist}
|
|
|
|
An expression statement evaluates the expression list (which may be a
|
|
single expression).
|
|
\indexii{expression}{list}
|
|
|
|
In interactive mode, if the value is not \code{None}, it is converted
|
|
to a string using the built-in \function{repr()}\bifuncindex{repr}
|
|
function and the resulting string is written to standard output (see
|
|
section~\ref{print}) on a line by itself. (Expression statements
|
|
yielding \code{None} are not written, so that procedure calls do not
|
|
cause any output.)
|
|
\ttindex{None}
|
|
\indexii{string}{conversion}
|
|
\index{output}
|
|
\indexii{standard}{output}
|
|
\indexii{writing}{values}
|
|
\indexii{procedure}{call}
|
|
|
|
|
|
\section{Assert statements \label{assert}}
|
|
|
|
Assert statements\stindex{assert} are a convenient way to insert
|
|
debugging assertions\indexii{debugging}{assertions} into a program:
|
|
|
|
\begin{productionlist}
|
|
\production{assert_statement}
|
|
{"assert" \token{expression} ["," \token{expression}]}
|
|
\end{productionlist}
|
|
|
|
The simple form, \samp{assert expression}, is equivalent to
|
|
|
|
\begin{verbatim}
|
|
if __debug__:
|
|
if not expression: raise AssertionError
|
|
\end{verbatim}
|
|
|
|
The extended form, \samp{assert expression1, expression2}, is
|
|
equivalent to
|
|
|
|
\begin{verbatim}
|
|
if __debug__:
|
|
if not expression1: raise AssertionError, expression2
|
|
\end{verbatim}
|
|
|
|
These equivalences assume that \code{__debug__}\ttindex{__debug__} and
|
|
\exception{AssertionError}\exindex{AssertionError} refer to the built-in
|
|
variables with those names. In the current implementation, the
|
|
built-in variable \code{__debug__} is 1 under normal circumstances, 0
|
|
when optimization is requested (command line option -O). The current
|
|
code generator emits no code for an assert statement when optimization
|
|
is requested at compile time. Note that it is unnecessary to include
|
|
the source code for the expression that failed in the error message;
|
|
it will be displayed as part of the stack trace.
|
|
|
|
Assignments to \code{__debug__} are illegal. The value for the
|
|
built-in variable is determined when the interpreter starts.
|
|
|
|
|
|
\section{Assignment statements \label{assignment}}
|
|
|
|
Assignment statements\indexii{assignment}{statement} are used to
|
|
(re)bind names to values and to modify attributes or items of mutable
|
|
objects:
|
|
\indexii{binding}{name}
|
|
\indexii{rebinding}{name}
|
|
\obindex{mutable}
|
|
\indexii{attribute}{assignment}
|
|
|
|
\begin{productionlist}
|
|
\production{assignment_stmt}
|
|
{(\token{target_list} "=")+ \token{expression_list}}
|
|
\production{target_list}
|
|
{\token{target} ("," \token{target})* [","]}
|
|
\production{target}
|
|
{\token{identifier}}
|
|
\productioncont{| "(" \token{target_list} ")"}
|
|
\productioncont{| "[" \token{target_list} "]"}
|
|
\productioncont{| \token{attributeref}}
|
|
\productioncont{| \token{subscription}}
|
|
\productioncont{| \token{slicing}}
|
|
\end{productionlist}
|
|
|
|
(See section~\ref{primaries} for the syntax definitions for the last
|
|
three symbols.)
|
|
|
|
An assignment statement evaluates the expression list (remember that
|
|
this can be a single expression or a comma-separated list, the latter
|
|
yielding a tuple) and assigns the single resulting object to each of
|
|
the target lists, from left to right.
|
|
\indexii{expression}{list}
|
|
|
|
Assignment is defined recursively depending on the form of the target
|
|
(list). When a target is part of a mutable object (an attribute
|
|
reference, subscription or slicing), the mutable object must
|
|
ultimately perform the assignment and decide about its validity, and
|
|
may raise an exception if the assignment is unacceptable. The rules
|
|
observed by various types and the exceptions raised are given with the
|
|
definition of the object types (see section~\ref{types}).
|
|
\index{target}
|
|
\indexii{target}{list}
|
|
|
|
Assignment of an object to a target list is recursively defined as
|
|
follows.
|
|
\indexiii{target}{list}{assignment}
|
|
|
|
\begin{itemize}
|
|
\item
|
|
If the target list is a single target: The object is assigned to that
|
|
target.
|
|
|
|
\item
|
|
If the target list is a comma-separated list of targets: The object
|
|
must be a sequence with the same number of items as the there are
|
|
targets in the target list, and the items are assigned, from left to
|
|
right, to the corresponding targets. (This rule is relaxed as of
|
|
Python 1.5; in earlier versions, the object had to be a tuple. Since
|
|
strings are sequences, an assignment like \samp{a, b = "xy"} is
|
|
now legal as long as the string has the right length.)
|
|
|
|
\end{itemize}
|
|
|
|
Assignment of an object to a single target is recursively defined as
|
|
follows.
|
|
|
|
\begin{itemize} % nested
|
|
|
|
\item
|
|
If the target is an identifier (name):
|
|
|
|
\begin{itemize}
|
|
|
|
\item
|
|
If the name does not occur in a \keyword{global} statement in the current
|
|
code block: the name is bound to the object in the current local
|
|
namespace.
|
|
\stindex{global}
|
|
|
|
\item
|
|
Otherwise: the name is bound to the object in the current global
|
|
namespace.
|
|
|
|
\end{itemize} % nested
|
|
|
|
The name is rebound if it was already bound. This may cause the
|
|
reference count for the object previously bound to the name to reach
|
|
zero, causing the object to be deallocated and its
|
|
destructor\index{destructor} (if it has one) to be called.
|
|
|
|
\item
|
|
If the target is a target list enclosed in parentheses or in square
|
|
brackets: The object must be a sequence with the same number of items
|
|
as there are targets in the target list, and its items are assigned,
|
|
from left to right, to the corresponding targets.
|
|
|
|
\item
|
|
If the target is an attribute reference: The primary expression in the
|
|
reference is evaluated. It should yield an object with assignable
|
|
attributes; if this is not the case, \exception{TypeError} is raised. That
|
|
object is then asked to assign the assigned object to the given
|
|
attribute; if it cannot perform the assignment, it raises an exception
|
|
(usually but not necessarily \exception{AttributeError}).
|
|
\indexii{attribute}{assignment}
|
|
|
|
\item
|
|
If the target is a subscription: The primary expression in the
|
|
reference is evaluated. It should yield either a mutable sequence
|
|
object (e.g., a list) or a mapping object (e.g., a dictionary). Next,
|
|
the subscript expression is evaluated.
|
|
\indexii{subscription}{assignment}
|
|
\obindex{mutable}
|
|
|
|
If the primary is a mutable sequence object (e.g., a list), the subscript
|
|
must yield a plain integer. If it is negative, the sequence's length
|
|
is added to it. The resulting value must be a nonnegative integer
|
|
less than the sequence's length, and the sequence is asked to assign
|
|
the assigned object to its item with that index. If the index is out
|
|
of range, \exception{IndexError} is raised (assignment to a subscripted
|
|
sequence cannot add new items to a list).
|
|
\obindex{sequence}
|
|
\obindex{list}
|
|
|
|
If the primary is a mapping object (e.g., a dictionary), the subscript must
|
|
have a type compatible with the mapping's key type, and the mapping is
|
|
then asked to create a key/datum pair which maps the subscript to
|
|
the assigned object. This can either replace an existing key/value
|
|
pair with the same key value, or insert a new key/value pair (if no
|
|
key with the same value existed).
|
|
\obindex{mapping}
|
|
\obindex{dictionary}
|
|
|
|
\item
|
|
If the target is a slicing: The primary expression in the reference is
|
|
evaluated. It should yield a mutable sequence object (e.g., a list). The
|
|
assigned object should be a sequence object of the same type. Next,
|
|
the lower and upper bound expressions are evaluated, insofar they are
|
|
present; defaults are zero and the sequence's length. The bounds
|
|
should evaluate to (small) integers. If either bound is negative, the
|
|
sequence's length is added to it. The resulting bounds are clipped to
|
|
lie between zero and the sequence's length, inclusive. Finally, the
|
|
sequence object is asked to replace the slice with the items of the
|
|
assigned sequence. The length of the slice may be different from the
|
|
length of the assigned sequence, thus changing the length of the
|
|
target sequence, if the object allows it.
|
|
\indexii{slicing}{assignment}
|
|
|
|
\end{itemize}
|
|
|
|
(In the current implementation, the syntax for targets is taken
|
|
to be the same as for expressions, and invalid syntax is rejected
|
|
during the code generation phase, causing less detailed error
|
|
messages.)
|
|
|
|
WARNING: Although the definition of assignment implies that overlaps
|
|
between the left-hand side and the right-hand side are `safe' (e.g.,
|
|
\samp{a, b = b, a} swaps two variables), overlaps \emph{within} the
|
|
collection of assigned-to variables are not safe! For instance, the
|
|
following program prints \samp{[0, 2]}:
|
|
|
|
\begin{verbatim}
|
|
x = [0, 1]
|
|
i = 0
|
|
i, x[i] = 1, 2
|
|
print x
|
|
\end{verbatim}
|
|
|
|
|
|
\subsection{Augmented assignment statements \label{augassign}}
|
|
|
|
Augmented assignment is the combination, in a single statement, of a binary
|
|
operation and an assignment statement:
|
|
\indexii{augmented}{assignment}
|
|
\index{statement!assignment, augmented}
|
|
|
|
\begin{productionlist}
|
|
\production{augmented_assignment_stmt}
|
|
{\token{target} \token{augop} \token{expression_list}}
|
|
\production{augop}
|
|
{"+=" | "-=" | "*=" | "/=" | "\%=" | "**="}
|
|
\productioncont{| ">>=" | "<<=" | "\&=" | "\textasciicircum=" | "|="}
|
|
\end{productionlist}
|
|
|
|
(See section~\ref{primaries} for the syntax definitions for the last
|
|
three symbols.)
|
|
|
|
An augmented assignment evaluates the target (which, unlike normal
|
|
assignment statements, cannot be an unpacking) and the expression
|
|
list, performs the binary operation specific to the type of assignment
|
|
on the two operands, and assigns the result to the original
|
|
target. The target is only evaluated once.
|
|
|
|
An augmented assignment expression like \code{x += 1} can be rewritten as
|
|
\code{x = x + 1} to achieve a similar, but not exactly equal effect. In the
|
|
augmented version, \code{x} is only evaluated once. Also, when possible, the
|
|
actual operation is performed \emph{in-place}, meaning that rather than
|
|
creating a new object and assigning that to the target, the old object is
|
|
modified instead.
|
|
|
|
With the exception of assigning to tuples and multiple targets in a single
|
|
statement, the assignment done by augmented assignment statements is handled
|
|
the same way as normal assignments. Similarly, with the exception of the
|
|
possible \emph{in-place} behavior, the binary operation performed by
|
|
augmented assignment is the same as the normal binary operations.
|
|
|
|
For targets which are attribute references, the initial value is
|
|
retrieved with a \method{getattr()} and the result is assigned with a
|
|
\method{setattr()}. Notice that the two methods do not necessarily
|
|
refer to the same variable. When \method{getattr()} refers to a class
|
|
variable, \method{setattr()} still writes to an instance variable.
|
|
For example:
|
|
|
|
\begin{verbatim}
|
|
class A:
|
|
x = 3 # class variable
|
|
a = A()
|
|
a.x += 1 # writes a.x as 4 leaving A.x as 3
|
|
\end{verbatim}
|
|
|
|
|
|
\section{The \keyword{pass} statement \label{pass}}
|
|
\stindex{pass}
|
|
|
|
\begin{productionlist}
|
|
\production{pass_stmt}
|
|
{"pass"}
|
|
\end{productionlist}
|
|
|
|
\keyword{pass} is a null operation --- when it is executed, nothing
|
|
happens. It is useful as a placeholder when a statement is
|
|
required syntactically, but no code needs to be executed, for example:
|
|
\indexii{null}{operation}
|
|
|
|
\begin{verbatim}
|
|
def f(arg): pass # a function that does nothing (yet)
|
|
|
|
class C: pass # a class with no methods (yet)
|
|
\end{verbatim}
|
|
|
|
|
|
\section{The \keyword{del} statement \label{del}}
|
|
\stindex{del}
|
|
|
|
\begin{productionlist}
|
|
\production{del_stmt}
|
|
{"del" \token{target_list}}
|
|
\end{productionlist}
|
|
|
|
Deletion is recursively defined very similar to the way assignment is
|
|
defined. Rather that spelling it out in full details, here are some
|
|
hints.
|
|
\indexii{deletion}{target}
|
|
\indexiii{deletion}{target}{list}
|
|
|
|
Deletion of a target list recursively deletes each target, from left
|
|
to right.
|
|
|
|
Deletion of a name removes the binding of that name
|
|
from the local or global namespace, depending on whether the name
|
|
occurs in a \keyword{global} statement in the same code block. If the
|
|
name is unbound, a \exception{NameError} exception will be raised.
|
|
\stindex{global}
|
|
\indexii{unbinding}{name}
|
|
|
|
It is illegal to delete a name from the local namespace if it occurs
|
|
as a free variable\indexii{free}{variable} in a nested block.
|
|
|
|
Deletion of attribute references, subscriptions and slicings
|
|
is passed to the primary object involved; deletion of a slicing
|
|
is in general equivalent to assignment of an empty slice of the
|
|
right type (but even this is determined by the sliced object).
|
|
\indexii{attribute}{deletion}
|
|
|
|
|
|
\section{The \keyword{print} statement \label{print}}
|
|
\stindex{print}
|
|
|
|
\begin{productionlist}
|
|
\production{print_stmt}
|
|
{"print" ( \optional{\token{expression} ("," \token{expression})* \optional{","}}}
|
|
\productioncont{| ">\code{>}" \token{expression}
|
|
\optional{("," \token{expression})+ \optional{","}} )}
|
|
\end{productionlist}
|
|
|
|
\keyword{print} evaluates each expression in turn and writes the
|
|
resulting object to standard output (see below). If an object is not
|
|
a string, it is first converted to a string using the rules for string
|
|
conversions. The (resulting or original) string is then written. A
|
|
space is written before each object is (converted and) written, unless
|
|
the output system believes it is positioned at the beginning of a
|
|
line. This is the case (1) when no characters have yet been written
|
|
to standard output, (2) when the last character written to standard
|
|
output is \character{\e n}, or (3) when the last write operation on
|
|
standard output was not a \keyword{print} statement. (In some cases
|
|
it may be functional to write an empty string to standard output for
|
|
this reason.) \note{Objects which act like file objects but which are
|
|
not the built-in file objects often do not properly emulate this
|
|
aspect of the file object's behavior, so it is best not to rely on
|
|
this.}
|
|
\index{output}
|
|
\indexii{writing}{values}
|
|
|
|
A \character{\e n} character is written at the end, unless the
|
|
\keyword{print} statement ends with a comma. This is the only action
|
|
if the statement contains just the keyword \keyword{print}.
|
|
\indexii{trailing}{comma}
|
|
\indexii{newline}{suppression}
|
|
|
|
Standard output is defined as the file object named \code{stdout}
|
|
in the built-in module \module{sys}. If no such object exists, or if
|
|
it does not have a \method{write()} method, a \exception{RuntimeError}
|
|
exception is raised.
|
|
\indexii{standard}{output}
|
|
\refbimodindex{sys}
|
|
\withsubitem{(in module sys)}{\ttindex{stdout}}
|
|
\exindex{RuntimeError}
|
|
|
|
\keyword{print} also has an extended\index{extended print statement}
|
|
form, defined by the second portion of the syntax described above.
|
|
This form is sometimes referred to as ``\keyword{print} chevron.''
|
|
In this form, the first expression after the \code{>}\code{>} must
|
|
evaluate to a ``file-like'' object, specifically an object that has a
|
|
\method{write()} method as described above. With this extended form,
|
|
the subsequent expressions are printed to this file object. If the
|
|
first expression evaluates to \code{None}, then \code{sys.stdout} is
|
|
used as the file for output.
|
|
|
|
|
|
\section{The \keyword{return} statement \label{return}}
|
|
\stindex{return}
|
|
|
|
\begin{productionlist}
|
|
\production{return_stmt}
|
|
{"return" [\token{expression_list}]}
|
|
\end{productionlist}
|
|
|
|
\keyword{return} may only occur syntactically nested in a function
|
|
definition, not within a nested class definition.
|
|
\indexii{function}{definition}
|
|
\indexii{class}{definition}
|
|
|
|
If an expression list is present, it is evaluated, else \code{None}
|
|
is substituted.
|
|
|
|
\keyword{return} leaves the current function call with the expression
|
|
list (or \code{None}) as return value.
|
|
|
|
When \keyword{return} passes control out of a \keyword{try} statement
|
|
with a \keyword{finally} clause, that \keyword{finally} clause is executed
|
|
before really leaving the function.
|
|
\kwindex{finally}
|
|
|
|
In a generator function, the \keyword{return} statement is not allowed
|
|
to include an \grammartoken{expression_list}. In that context, a bare
|
|
\keyword{return} indicates that the generator is done and will cause
|
|
\exception{StopIteration} to be raised.
|
|
|
|
|
|
\section{The \keyword{yield} statement \label{yield}}
|
|
\stindex{yield}
|
|
|
|
\begin{productionlist}
|
|
\production{yield_stmt}
|
|
{"yield" \token{expression_list}}
|
|
\end{productionlist}
|
|
|
|
\index{generator!function}
|
|
\index{generator!iterator}
|
|
\index{function!generator}
|
|
\exindex{StopIteration}
|
|
|
|
The \keyword{yield} statement is only used when defining a generator
|
|
function, and is only used in the body of the generator function.
|
|
Using a \keyword{yield} statement in a function definition is
|
|
sufficient to cause that definition to create a generator function
|
|
instead of a normal function.
|
|
|
|
When a generator function is called, it returns an iterator known as a
|
|
generator iterator, or more commonly, a generator. The body of the
|
|
generator function is executed by calling the generator's
|
|
\method{next()} method repeatedly until it raises an exception.
|
|
|
|
When a \keyword{yield} statement is executed, the state of the
|
|
generator is frozen and the value of \grammartoken{expression_list} is
|
|
returned to \method{next()}'s caller. By ``frozen'' we mean that all
|
|
local state is retained, including the current bindings of local
|
|
variables, the instruction pointer, and the internal evaluation stack:
|
|
enough information is saved so that the next time \method{next()} is
|
|
invoked, the function can proceed exactly as if the \keyword{yield}
|
|
statement were just another external call.
|
|
|
|
The \keyword{yield} statement is not allowed in the \keyword{try}
|
|
clause of a \keyword{try} ...\ \keyword{finally} construct. The
|
|
difficulty is that there's no guarantee the generator will ever be
|
|
resumed, hence no guarantee that the \keyword{finally} block will ever
|
|
get executed.
|
|
|
|
\begin{notice}
|
|
In Python 2.2, the \keyword{yield} statement is only allowed
|
|
when the \code{generators} feature has been enabled. It will always
|
|
be enabled in Python 2.3. This \code{__future__} import statment can
|
|
be used to enable the feature:
|
|
|
|
\begin{verbatim}
|
|
from __future__ import generators
|
|
\end{verbatim}
|
|
\end{notice}
|
|
|
|
|
|
\begin{seealso}
|
|
\seepep{0255}{Simple Generators}
|
|
{The proposal for adding generators and the \keyword{yield}
|
|
statement to Python.}
|
|
\end{seealso}
|
|
|
|
|
|
\section{The \keyword{raise} statement \label{raise}}
|
|
\stindex{raise}
|
|
|
|
\begin{productionlist}
|
|
\production{raise_stmt}
|
|
{"raise" [\token{expression} ["," \token{expression}
|
|
["," \token{expression}]]]}
|
|
\end{productionlist}
|
|
|
|
If no expressions are present, \keyword{raise} re-raises the last
|
|
expression that was active in the current scope. If no exception has
|
|
been active in the current scope, an exception is raised that
|
|
indicates indicates that this is the error.
|
|
\index{exception}
|
|
\indexii{raising}{exception}
|
|
|
|
Otherwise, \keyword{raise} evaluates the expressions to get three
|
|
objects, using \code{None} as the value of omitted expressions. The
|
|
first two objects are used to determine the \emph{type} and
|
|
\emph{value} of the exception.
|
|
|
|
If the first object is an instance, the type of the exception is the
|
|
class of the instance, the instance itself if the value, and the
|
|
second object must be \code{None}.
|
|
|
|
If the first object is a class, it becomes the type of the exception.
|
|
The second object is used to determine the exception value: If it is
|
|
an instance of the class, the instance becomes the exception value.
|
|
If the second object is a tuple, it is used as the argument list for
|
|
the class constructor; if it is \code{None}, an empty argument list is
|
|
used, and any other object is treated as a single argument to the
|
|
constructor. The instance so created by calling the constructor is
|
|
used as the exception value.
|
|
|
|
If the first object is a string, the string object is the exception
|
|
type, and the second object becomes the exception value.
|
|
|
|
If a third object is present and not \code{None}, it must be a
|
|
traceback\obindex{traceback} object (see section~\ref{traceback}), and
|
|
it is substituted instead of the current location as the place where
|
|
the exception occurred. If the third object is present and not a
|
|
traceback object or \code{None}, a \exception{TypeError} exception is
|
|
raised. The three-expression form of \keyword{raise} is useful to
|
|
re-raise an exception transparently in an except clause, but
|
|
\keyword{raise} with no expressions should be preferred if the
|
|
exception to be re-raised was the most recently active exception in
|
|
the current scope.
|
|
|
|
|
|
|
|
\section{The \keyword{break} statement \label{break}}
|
|
\stindex{break}
|
|
|
|
\begin{productionlist}
|
|
\production{break_stmt}
|
|
{"break"}
|
|
\end{productionlist}
|
|
|
|
\keyword{break} may only occur syntactically nested in a \keyword{for}
|
|
or \keyword{while} loop, but not nested in a function or class definition
|
|
within that loop.
|
|
\stindex{for}
|
|
\stindex{while}
|
|
\indexii{loop}{statement}
|
|
|
|
It terminates the nearest enclosing loop, skipping the optional
|
|
\keyword{else} clause if the loop has one.
|
|
\kwindex{else}
|
|
|
|
If a \keyword{for} loop is terminated by \keyword{break}, the loop control
|
|
target keeps its current value.
|
|
\indexii{loop control}{target}
|
|
|
|
When \keyword{break} passes control out of a \keyword{try} statement
|
|
with a \keyword{finally} clause, that \keyword{finally} clause is executed
|
|
before really leaving the loop.
|
|
\kwindex{finally}
|
|
|
|
|
|
\section{The \keyword{continue} statement \label{continue}}
|
|
\stindex{continue}
|
|
|
|
\begin{productionlist}
|
|
\production{continue_stmt}
|
|
{"continue"}
|
|
\end{productionlist}
|
|
|
|
\keyword{continue} may only occur syntactically nested in a \keyword{for} or
|
|
\keyword{while} loop, but not nested in a function or class definition or
|
|
\keyword{try} statement within that loop.\footnote{It may
|
|
occur within an \keyword{except} or \keyword{else} clause. The
|
|
restriction on occurring in the \keyword{try} clause is implementor's
|
|
laziness and will eventually be lifted.}
|
|
It continues with the next cycle of the nearest enclosing loop.
|
|
\stindex{for}
|
|
\stindex{while}
|
|
\indexii{loop}{statement}
|
|
\kwindex{finally}
|
|
|
|
|
|
\section{The \keyword{import} statement \label{import}}
|
|
\stindex{import}
|
|
|
|
\begin{productionlist}
|
|
\production{import_stmt}
|
|
{"import" \token{module} ["as" \token{name}]
|
|
( "," \token{module} ["as" \token{name}] )*}
|
|
\productioncont{| "from" \token{module} "import" \token{identifier}
|
|
["as" \token{name}]}
|
|
\productioncont{ ( "," \token{identifier} ["as" \token{name}] )*}
|
|
\productioncont{| "from" \token{module} "import" "*"}
|
|
\production{module}
|
|
{(\token{identifier} ".")* \token{identifier}}
|
|
\end{productionlist}
|
|
|
|
Import statements are executed in two steps: (1) find a module, and
|
|
initialize it if necessary; (2) define a name or names in the local
|
|
namespace (of the scope where the \keyword{import} statement occurs).
|
|
The first form (without \keyword{from}) repeats these steps for each
|
|
identifier in the list. The form with \keyword{from} performs step
|
|
(1) once, and then performs step (2) repeatedly.
|
|
\indexii{importing}{module}
|
|
\indexii{name}{binding}
|
|
\kwindex{from}
|
|
% XXX Need to define what ``initialize'' means here
|
|
|
|
The system maintains a table of modules that have been initialized,
|
|
indexed by module name. This table is
|
|
accessible as \code{sys.modules}. When a module name is found in
|
|
this table, step (1) is finished. If not, a search for a module
|
|
definition is started. When a module is found, it is loaded. Details
|
|
of the module searching and loading process are implementation and
|
|
platform specific. It generally involves searching for a ``built-in''
|
|
module with the given name and then searching a list of locations
|
|
given as \code{sys.path}.
|
|
\withsubitem{(in module sys)}{\ttindex{modules}}
|
|
\ttindex{sys.modules}
|
|
\indexii{module}{name}
|
|
\indexii{built-in}{module}
|
|
\indexii{user-defined}{module}
|
|
\refbimodindex{sys}
|
|
\indexii{filename}{extension}
|
|
\indexiii{module}{search}{path}
|
|
|
|
If a built-in module is found, its built-in initialization code is
|
|
executed and step (1) is finished. If no matching file is found,
|
|
\exception{ImportError} is raised. If a file is found, it is parsed,
|
|
yielding an executable code block. If a syntax error occurs,
|
|
\exception{SyntaxError} is raised. Otherwise, an empty module of the given
|
|
name is created and inserted in the module table, and then the code
|
|
block is executed in the context of this module. Exceptions during
|
|
this execution terminate step (1).
|
|
\indexii{module}{initialization}
|
|
\exindex{SyntaxError}
|
|
\exindex{ImportError}
|
|
\index{code block}
|
|
|
|
When step (1) finishes without raising an exception, step (2) can
|
|
begin.
|
|
|
|
The first form of \keyword{import} statement binds the module name in
|
|
the local namespace to the module object, and then goes on to import
|
|
the next identifier, if any. If the module name is followed by
|
|
\keyword{as}, the name following \keyword{as} is used as the local
|
|
name for the module. To avoid confusion, you cannot import modules
|
|
with dotted names \keyword{as} a different local name. So \code{import
|
|
module as m} is legal, but \code{import module.submod as s} is not.
|
|
The latter should be written as \code{from module import submod as s};
|
|
see below.
|
|
|
|
The \keyword{from} form does not bind the module name: it goes through the
|
|
list of identifiers, looks each one of them up in the module found in step
|
|
(1), and binds the name in the local namespace to the object thus found.
|
|
As with the first form of \keyword{import}, an alternate local name can be
|
|
supplied by specifying "\keyword{as} localname". If a name is not found,
|
|
\exception{ImportError} is raised. If the list of identifiers is replaced
|
|
by a star (\character{*}), all public names defined in the module are
|
|
bound in the local namespace of the \keyword{import} statement..
|
|
\indexii{name}{binding}
|
|
\exindex{ImportError}
|
|
|
|
The \emph{public names} defined by a module are determined by checking
|
|
the module's namespace for a variable named \code{__all__}; if
|
|
defined, it must be a sequence of strings which are names defined or
|
|
imported by that module. The names given in \code{__all__} are all
|
|
considered public and are required to exist. If \code{__all__} is not
|
|
defined, the set of public names includes all names found in the
|
|
module's namespace which do not begin with an underscore character
|
|
(\character{_}).
|
|
|
|
The \keyword{from} form with \samp{*} may only occur in a module
|
|
scope. If the wild card form of import --- \samp{import *} --- is
|
|
used in a function and the function contains or is a nested block with
|
|
free variables, the compiler will raise a \exception{SyntaxError}.
|
|
|
|
\kwindex{from}
|
|
\stindex{from}
|
|
|
|
\strong{Hierarchical module names:}\indexiii{hierarchical}{module}{names}
|
|
when the module names contains one or more dots, the module search
|
|
path is carried out differently. The sequence of identifiers up to
|
|
the last dot is used to find a ``package''\index{packages}; the final
|
|
identifier is then searched inside the package. A package is
|
|
generally a subdirectory of a directory on \code{sys.path} that has a
|
|
file \file{__init__.py}.\ttindex{__init__.py}
|
|
%
|
|
[XXX Can't be bothered to spell this out right now; see the URL
|
|
\url{http://www.python.org/doc/essays/packages.html} for more details, also
|
|
about how the module search works from inside a package.]
|
|
|
|
The built-in function \function{__import__()} is provided to support
|
|
applications that determine which modules need to be loaded
|
|
dynamically; refer to \ulink{Built-in
|
|
Functions}{../lib/built-in-funcs.html} in the
|
|
\citetitle[../lib/lib.html]{Python Library Reference} for additional
|
|
information.
|
|
\bifuncindex{__import__}
|
|
|
|
|
|
\section{The \keyword{global} statement \label{global}}
|
|
\stindex{global}
|
|
|
|
\begin{productionlist}
|
|
\production{global_stmt}
|
|
{"global" \token{identifier} ("," \token{identifier})*}
|
|
\end{productionlist}
|
|
|
|
The \keyword{global} statement is a declaration which holds for the
|
|
entire current code block. It means that the listed identifiers are to be
|
|
interpreted as globals. It would be impossible to assign to a global
|
|
variable without \keyword{global}, although free variables may refer
|
|
to globals without being declared global.
|
|
\indexiii{global}{name}{binding}
|
|
|
|
Names listed in a \keyword{global} statement must not be used in the same
|
|
code block textually preceding that \keyword{global} statement.
|
|
|
|
Names listed in a \keyword{global} statement must not be defined as formal
|
|
parameters or in a \keyword{for} loop control target, \keyword{class}
|
|
definition, function definition, or \keyword{import} statement.
|
|
|
|
(The current implementation does not enforce the latter two
|
|
restrictions, but programs should not abuse this freedom, as future
|
|
implementations may enforce them or silently change the meaning of the
|
|
program.)
|
|
|
|
\strong{Programmer's note:}
|
|
the \keyword{global} is a directive to the parser. It
|
|
applies only to code parsed at the same time as the \keyword{global}
|
|
statement. In particular, a \keyword{global} statement contained in an
|
|
\keyword{exec} statement does not affect the code block \emph{containing}
|
|
the \keyword{exec} statement, and code contained in an \keyword{exec}
|
|
statement is unaffected by \keyword{global} statements in the code
|
|
containing the \keyword{exec} statement. The same applies to the
|
|
\function{eval()}, \function{execfile()} and \function{compile()} functions.
|
|
\stindex{exec}
|
|
\bifuncindex{eval}
|
|
\bifuncindex{execfile}
|
|
\bifuncindex{compile}
|
|
|
|
|
|
\section{The \keyword{exec} statement \label{exec}}
|
|
\stindex{exec}
|
|
|
|
\begin{productionlist}
|
|
\production{exec_stmt}
|
|
{"exec" \token{expression}
|
|
["in" \token{expression} ["," \token{expression}]]}
|
|
\end{productionlist}
|
|
|
|
This statement supports dynamic execution of Python code. The first
|
|
expression should evaluate to either a string, an open file object, or
|
|
a code object. If it is a string, the string is parsed as a suite of
|
|
Python statements which is then executed (unless a syntax error
|
|
occurs). If it is an open file, the file is parsed until \EOF{} and
|
|
executed. If it is a code object, it is simply executed.
|
|
|
|
In all cases, if the optional parts are omitted, the code is executed
|
|
in the current scope. If only the first expression after \keyword{in}
|
|
is specified, it should be a dictionary, which will be used for both
|
|
the global and the local variables. If two expressions are given,
|
|
both must be dictionaries and they are used for the global and local
|
|
variables, respectively.
|
|
|
|
As a side effect, an implementation may insert additional keys into
|
|
the dictionaries given besides those corresponding to variable names
|
|
set by the executed code. For example, the current implementation
|
|
may add a reference to the dictionary of the built-in module
|
|
\module{__builtin__} under the key \code{__builtins__} (!).
|
|
\ttindex{__builtins__}
|
|
\refbimodindex{__builtin__}
|
|
|
|
\strong{Programmer's hints:}
|
|
dynamic evaluation of expressions is supported by the built-in
|
|
function \function{eval()}. The built-in functions
|
|
\function{globals()} and \function{locals()} return the current global
|
|
and local dictionary, respectively, which may be useful to pass around
|
|
for use by \keyword{exec}.
|
|
\bifuncindex{eval}
|
|
\bifuncindex{globals}
|
|
\bifuncindex{locals}
|
|
|
|
Also, in the current implementation, multi-line compound statements must
|
|
end with a newline:
|
|
\code{exec "for v in seq:\e{}n\e{}tprint v\e{}n"} works, but
|
|
\code{exec "for v in seq:\e{}n\e{}tprint v"} fails with
|
|
\exception{SyntaxError}.
|
|
\exindex{SyntaxError}
|
|
|
|
|