4.1 Code blocks, execution frames, and namespaces

 

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 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 `-c' option) is a code block. The file read by the built-in function execfile() is a code block. The string argument passed to the built-in function eval() and to the exec statement is a code block. And finally, the expression read and evaluated by the built-in function 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 the environment in which names are resolved.

A namespace s a mapping from names (identifiers) to objects. An environment is a hierarchical collection of the namespaces that are visible to a particular code block. Python namespaces are statically scoped in the tradition of Algol, but also has global statement that can be used to access the top-level namespace on the environment.

Names refers to objects. Names are introduced by name binding operations. Each occurrence of a name in the program text refers to the binding of that name established in the innermost function namespace containing the use. Changing the mapping of a name to an object is called rebinding ; removing a name is unbinding . Namespaces are functionally equivalent to dictionaries (and often implemented as dictionaries).

When a name is bound, a mapping is created in the local namespace of the execution frame unless the name is declared global. If a name binding operation occurs anywhere within a code block, all uses of the name within the block are treated as references to the local namespace. (Note: This can lead to errors when a name is used within a block before it is bound.)

The global namespace determines the place where names listed in global statements are defined and searched. The global namespace of a block is the namespace of the module in which the block was defined.

If a name is used within a code block, but it is not bound there and is not declared global, it is a free variable  . A free variable is resolved using the nearest enclosing function block that has a binding for the name. If no such block exists, the name is resolved in the global namespace.

When a name is not found at all, a NameError  exception is raised.

The local namespace of a class definition becomes the attribute dictionary of the class. If a block is contained within a class definition, the name bindings that occur in the containing class block are not visible to enclosed blocks.

The following constructs bind names: formal parameters to functions, import statements, class and function definitions (these bind the class or function name in the defining block), and identifiers occurring as the target of an assignment, in a for loop header (including list comprehensions), or in the second position of an except clause.

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 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 global statement forces global interpretation of selected names throughout the code block.

The following constructs bind names: formal parameters to functions, 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, for loop header, or in the second position of an except clause header. The import statement of the form ``"from ...import *"'' binds all names defined in the imported module, except those beginning with an underscore. This form may only be used at the module level.

A target occurring in a del statement is also considered bound for this purpose (though the actual semantics are to unbind the name). It is illegal to unbind a name that is referenced by an enclosing scope; the compiler will report a SyntaxError.

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 __builtin__ ). The built-in namespace associated with the execution of a code block is actually found by looking up the name __builtins__ in its global namespace; this should be a dictionary or a module (in the latter case the module's dictionary is used). Normally, the __builtins__ namespace is the dictionary of the built-in module __builtin__ (note: no `s'). If it isn't, restricted execution mode is in effect.

The namespace for a module is automatically created the first time a module is imported. The main module for a script is always called __main__ .

The eval(), execfile(), and input() functions and the exec statement do not have access to the full environment for resolving names. Names may be resolved in the local and global namespaces of the caller. Free variables are not resolved in the nearest enclosing namespaces, but in the global namespace.4.1The exec statement and the eval() and execfile() functions have optional arguments to override the global and local namespace. If only one namespace is specified, it is used for both.

The built-in functions globals() and locals() each return a dictionary, representing the current global and local namespace respectively. The effect of modifications to these dictionaries on the namespace are undefined.4.2



Footnotes

... namespace.4.1
This limitation occurs because the code that is executed by these operations is not available at the time the module is compiled.
... undefined.4.2
The current implementations return the dictionary actually used to implement the namespace, except for functions, where the optimizer may cause the local namespace to be implemented differently, and locals() returns a read-only dictionary.
See About this document... for information on suggesting changes.