mirror of
				https://github.com/python/cpython.git
				synced 2025-10-30 21:21:22 +00:00 
			
		
		
		
	
		
			
				
	
	
		
			215 lines
		
	
	
	
		
			9.7 KiB
		
	
	
	
		
			TeX
		
	
	
	
	
	
			
		
		
	
	
			215 lines
		
	
	
	
		
			9.7 KiB
		
	
	
	
		
			TeX
		
	
	
	
	
	
| \chapter{Execution model \label{execmodel}}
 | |
| \index{execution model}
 | |
| 
 | |
| 
 | |
| \section{Code blocks, execution frames, and namespaces \label{execframes}}
 | |
| \index{code block}
 | |
| \index{namespace}
 | |
| \indexii{execution}{frame}
 | |
| 
 | |
| A \dfn{code block}\indexii{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 normally 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.
 | |
| 
 | |
| 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 (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
 | |
| `\strong{-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.
 | |
| 
 | |
| A code block is executed in an execution frame.  An \dfn{execution
 | |
| frame}\indexii{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 namespaces, the local and the global
 | |
| namespace, that affect execution of the code block.
 | |
| 
 | |
| A \dfn{namespace}\index{namespace} is a mapping from names
 | |
| (identifiers) to objects.  A particular namespace may be referenced by
 | |
| more than one execution frame, and from other places as well.  Adding
 | |
| a name to a namespace is called \dfn{binding}\indexii{binding}{name} a
 | |
| name (to an object); changing the mapping of a name is called
 | |
| \dfn{rebinding}\indexii{rebinding}{name}; removing a name is
 | |
| \dfn{unbinding}\indexii{unbinding}{name}.  Namespaces are functionally
 | |
| equivalent to dictionaries (and often implemented as dictionaries).
 | |
| 
 | |
| The \dfn{local namespace}\indexii{local}{namespace} of an execution
 | |
| frame determines the default place where names are defined and
 | |
| searched.  The
 | |
| \dfn{global namespace}\indexii{global}{namespace} determines the place
 | |
| where names listed in \keyword{global}\stindex{global} statements are
 | |
| defined and searched, and where names that are not bound anywhere 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 \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
 | |
| interpretation of selected names throughout the code block.  The
 | |
| 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.}
 | |
| 
 | |
| A target occurring in a \keyword{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 namespace, it is
 | |
| searched in the built-in namespace (which is actually the global
 | |
| namespace of the module
 | |
| \module{__builtin__}\refbimodindex{__builtin__}).  The built-in
 | |
| namespace associated with the execution of a code block is actually
 | |
| found by looking up the name \code{__builtins__} in 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\indexii{restricted}{execution} mode is in effect.  When a 
 | |
| name is not found at all, a
 | |
| \exception{NameError}\withsubitem{(built-in
 | |
| exception)}{\ttindex{NameError}} exception is raised.
 | |
| \stindex{from}
 | |
| \stindex{exec}
 | |
| \stindex{global}
 | |
| 
 | |
| The following table lists the meaning of the local and global
 | |
| namespace for various types of code blocks.  The namespace for a
 | |
| particular module is automatically created when the module is first
 | |
| 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!
 | |
| 
 | |
| \begin{tableiv}{l|l|l|l}{textrm}
 | |
|   {Code block type}{Global namespace}{Local namespace}{Notes}
 | |
|   \lineiv{Module}
 | |
|          {n.s. for this module}
 | |
|          {same as global}{}
 | |
|   \lineiv{Script (file or command)}
 | |
|          {n.s. for \module{__main__}\refbimodindex{__main__}}
 | |
|          {same as global}{(1)}
 | |
|   \lineiv{Interactive command}
 | |
|          {n.s. for \module{__main__}\refbimodindex{__main__}}
 | |
|          {same as global}{}
 | |
|   \lineiv{Class definition}
 | |
|          {global n.s. of containing block}
 | |
|          {new n.s.}{}
 | |
|   \lineiv{Function body}
 | |
|          {global n.s. of containing block}
 | |
|          {new n.s.}{(2)}
 | |
|   \lineiv{String passed to \keyword{exec} statement}
 | |
|          {global n.s. of containing block}
 | |
|          {local n.s. of containing block}{(2), (3)}
 | |
|   \lineiv{String passed to \function{eval()}}
 | |
|          {global n.s. of caller}
 | |
|          {local n.s. of caller}{(2), (3)}
 | |
|   \lineiv{File read by \function{execfile()}}
 | |
|          {global n.s. of caller}
 | |
|          {local n.s. of caller}{(2), (3)}
 | |
|   \lineiv{Expression read by \function{input()}}
 | |
|          {global n.s. of caller}
 | |
|          {local n.s. of caller}{}
 | |
| \end{tableiv}
 | |
| 
 | |
| Notes:
 | |
| 
 | |
| \begin{description}
 | |
| 
 | |
| \item[n.s.] means \emph{namespace}
 | |
| 
 | |
| \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
 | |
| overridden with optional extra arguments.
 | |
| 
 | |
| \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.
 | |
| 
 | |
| \end{description}
 | |
| 
 | |
| The built-in functions \function{globals()} and \function{locals()} returns a
 | |
| dictionary representing the current global and local namespace,
 | |
| respectively.  The effect of modifications to this dictionary on the
 | |
| namespace are undefined.\footnote{
 | |
|   The current implementations return the dictionary actually used to
 | |
|   implement the namespace, \emph{except} for functions, where the
 | |
|   optimizer may cause the local namespace to be implemented
 | |
|   differently, and \function{locals()} returns a read-only
 | |
|   dictionary.}
 | |
| 
 | |
| 
 | |
| \section{Exceptions \label{exceptions}}
 | |
| \index{exception}
 | |
| 
 | |
| 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
 | |
| \emph{raised}\index{raise an exception} at the point where the error
 | |
| is detected; it may be \emph{handled}\index{handle an exception} by
 | |
| the surrounding code block or by any code block that directly or
 | |
| indirectly invoked the code block where the error occurred.
 | |
| \index{exception handler}
 | |
| \index{errors}
 | |
| \index{error handling}
 | |
| 
 | |
| The Python interpreter raises an exception when it detects a run-time
 | |
| 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}
 | |
| 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.
 | |
| 
 | |
| Python uses the ``termination'' \index{termination model}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 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.  In
 | |
| either case, it prints a stack backtrace, except when the exception is 
 | |
| \exception{SystemExit}\withsubitem{(built-in
 | |
| exception)}{\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.
 | |
| 
 | |
| When an exception is raised, an object (maybe \code{None}) is passed
 | |
| 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.
 | |
| 
 | |
| See also the description of the \keyword{try} statement in section
 | |
| \ref{try} and \keyword{raise} statement in section \ref{raise}.
 | 
