When referring to namespaces, always say "namespaces" instead of

freddrake · freddrake · commit 1349437e4c2b · 2000-09-12T16:23:48.000Z
"name spaces".

Inconsistency noted by Keith Briggs &lt;keith.briggs@bt.com&gt;.
diff --git a/Doc/lib/libdis.tex b/Doc/lib/libdis.tex
@@ -480,9 +480,9 @@ \subsection{Python Byte Code Instructions}
 
 \begin{opcodedesc}{IMPORT_NAME}{namei}
 Imports the module \code{co_names[\var{namei}]}.  The module object is
-pushed onto the stack.  The current name space is not affected: for a
+pushed onto the stack.  The current namespace is not affected: for a
 proper import statement, a subsequent \code{STORE_FAST} instruction
-modifies the name space.
+modifies the namespace.
 \end{opcodedesc}
 
 \begin{opcodedesc}{IMPORT_FROM}{namei}
diff --git a/Doc/lib/libfuncs.tex b/Doc/lib/libfuncs.tex
@@ -227,7 +227,7 @@ \section{Built-in Functions \label{built-in-funcs}}
   The arguments are a file name and two optional dictionaries.  The
   file is parsed and evaluated as a sequence of Python statements
   (similarly to a module) using the \var{globals} and \var{locals}
-  dictionaries as global and local name space.  If the \var{locals}
+  dictionaries as global and local namespace.  If the \var{locals}
   dictionary is omitted it defaults to the \var{globals} dictionary.
   If both dictionaries are omitted, the expression is executed in the
   environment where \function{execfile()} is called.  The return value is
diff --git a/Doc/lib/libstdtypes.tex b/Doc/lib/libstdtypes.tex
@@ -888,7 +888,7 @@ \subsubsection{Functions \label{typesfunctions}}
 The implementation adds two special read-only attributes:
 \code{\var{f}.func_code} is a function's \dfn{code
 object}\obindex{code} (see below) and \code{\var{f}.func_globals} is
-the dictionary used as the function's global name space (this is the
+the dictionary used as the function's global namespace (this is the
 same as \code{\var{m}.__dict__} where \var{m} is the module in which
 the function \var{f} was defined).
 
diff --git a/Doc/tut/tut.tex b/Doc/tut/tut.tex
@@ -317,7 +317,7 @@ \subsection{The Interactive Startup File \label{startup}}
 This file is only read in interactive sessions, not when Python reads
 commands from a script, and not when \file{/dev/tty} is given as the
 explicit source of commands (which otherwise behaves like an
-interactive session).  It is executed in the same name space where
+interactive session).  It is executed in the same namespace where
 interactive commands are executed, so that objects that it defines or
 imports can be used without qualification in the interactive session.
 You can also change the prompts \code{sys.ps1} and \code{sys.ps2} in
@@ -3236,24 +3236,24 @@ \section{Python Scopes and Name Spaces \label{scopes}}
 
 Before introducing classes, I first have to tell you something about
 Python's scope rules.  Class definitions play some neat tricks with
-name spaces, and you need to know how scopes and name spaces work to
+namespaces, and you need to know how scopes and namespaces work to
 fully understand what's going on.  Incidentally, knowledge about this
 subject is useful for any advanced Python programmer.
 
 Let's begin with some definitions.
 
-A \emph{name space} is a mapping from names to objects.  Most name
-spaces are currently implemented as Python dictionaries, but that's
-normally not noticeable in any way (except for performance), and it
-may change in the future.  Examples of name spaces are: the set of
-built-in names (functions such as \function{abs()}, and built-in exception
-names); the global names in a module; and the local names in a
-function invocation.  In a sense the set of attributes of an object
-also form a name space.  The important thing to know about name
-spaces is that there is absolutely no relation between names in
-different name spaces; for instance, two different modules may both
-define a function ``maximize'' without confusion --- users of the
-modules must prefix it with the module name.
+A \emph{namespace} is a mapping from names to objects.  Most
+namespaces are currently implemented as Python dictionaries, but
+that's normally not noticeable in any way (except for performance),
+and it may change in the future.  Examples of namespaces are: the set
+of built-in names (functions such as \function{abs()}, and built-in
+exception names); the global names in a module; and the local names in
+a function invocation.  In a sense the set of attributes of an object
+also form a namespace.  The important thing to know about namespaces
+is that there is absolutely no relation between names in different
+namespaces; for instance, two different modules may both define a
+function ``maximize'' without confusion --- users of the modules must
+prefix it with the module name.
 
 By the way, I use the word \emph{attribute} for any name following a
 dot --- for example, in the expression \code{z.real}, \code{real} is
@@ -3262,13 +3262,13 @@ \section{Python Scopes and Name Spaces \label{scopes}}
 \code{modname.funcname}, \code{modname} is a module object and
 \code{funcname} is an attribute of it.  In this case there happens to
 be a straightforward mapping between the module's attributes and the
-global names defined in the module: they share the same name
-space!\footnote{
+global names defined in the module: they share the same namespace!
+\footnote{
         Except for one thing.  Module objects have a secret read-only
-        attribute called \code{__dict__} which returns the dictionary
-        used to implement the module's name space; the name
-        \code{__dict__} is an attribute but not a global name.
-        Obviously, using this violates the abstraction of name space
+        attribute called \member{__dict__} which returns the dictionary
+        used to implement the module's namespace; the name
+        \member{__dict__} is an attribute but not a global name.
+        Obviously, using this violates the abstraction of namespace
         implementation, and should be restricted to things like
         post-mortem debuggers.
 }
@@ -3280,54 +3280,54 @@ \section{Python Scopes and Name Spaces \label{scopes}}
 \samp{del modname.the_answer}.
 
 Name spaces are created at different moments and have different
-lifetimes.  The name space containing the built-in names is created
+lifetimes.  The namespace containing the built-in names is created
 when the Python interpreter starts up, and is never deleted.  The
-global name space for a module is created when the module definition
-is read in; normally, module name spaces also last until the
+global namespace for a module is created when the module definition
+is read in; normally, module namespaces also last until the
 interpreter quits.  The statements executed by the top-level
 invocation of the interpreter, either read from a script file or
 interactively, are considered part of a module called
-\module{__main__}, so they have their own global name space.  (The
+\module{__main__}, so they have their own global namespace.  (The
 built-in names actually also live in a module; this is called
 \module{__builtin__}.)
 
-The local name space for a function is created when the function is
+The local namespace for a function is created when the function is
 called, and deleted when the function returns or raises an exception
 that is not handled within the function.  (Actually, forgetting would
 be a better way to describe what actually happens.)  Of course,
-recursive invocations each have their own local name space.
+recursive invocations each have their own local namespace.
 
-A \emph{scope} is a textual region of a Python program where a name space
-is directly accessible.  ``Directly accessible'' here means that an
-unqualified reference to a name attempts to find the name in the name
-space.
+A \emph{scope} is a textual region of a Python program where a
+namespace is directly accessible.  ``Directly accessible'' here means
+that an unqualified reference to a name attempts to find the name in
+the namespace.
 
 Although scopes are determined statically, they are used dynamically.
 At any time during execution, exactly three nested scopes are in use
-(i.e., exactly three name spaces are directly accessible): the
+(i.e., exactly three namespaces are directly accessible): the
 innermost scope, which is searched first, contains the local names,
 the middle scope, searched next, contains the current module's global
-names, and the outermost scope (searched last) is the name space
+names, and the outermost scope (searched last) is the namespace
 containing built-in names.
 
 Usually, the local scope references the local names of the (textually)
 current function.  Outside of functions, the local scope references
-the same name space as the global scope: the module's name space.
-Class definitions place yet another name space in the local scope.
+the same namespace as the global scope: the module's namespace.
+Class definitions place yet another namespace in the local scope.
 
 It is important to realize that scopes are determined textually: the
-global scope of a function defined in a module is that module's name
-space, no matter from where or by what alias the function is called.
-On the other hand, the actual search for names is done dynamically, at
-run time --- however, the language definition is evolving towards
-static name resolution, at ``compile'' time, so don't rely on dynamic
-name resolution!  (In fact, local variables are already determined
-statically.)
+global scope of a function defined in a module is that module's
+namespace, no matter from where or by what alias the function is
+called.  On the other hand, the actual search for names is done
+dynamically, at run time --- however, the language definition is
+evolving towards static name resolution, at ``compile'' time, so don't
+rely on dynamic name resolution!  (In fact, local variables are
+already determined statically.)
 
 A special quirk of Python is that assignments always go into the
 innermost scope.  Assignments do not copy data --- they just
 bind names to objects.  The same is true for deletions: the statement
-\samp{del x} removes the binding of \code{x} from the name space
+\samp{del x} removes the binding of \code{x} from the namespace
 referenced by the local scope.  In fact, all operations that introduce
 new names use the local scope: in particular, import statements and
 function definitions bind the module or function name in the local
@@ -3366,14 +3366,14 @@ \subsection{Class Definition Syntax \label{classDefinition}}
 dictated by the calling conventions for methods --- again, this is
 explained later.
 
-When a class definition is entered, a new name space is created, and
+When a class definition is entered, a new namespace is created, and
 used as the local scope --- thus, all assignments to local variables
-go into this new name space.  In particular, function definitions bind
+go into this new namespace.  In particular, function definitions bind
 the name of the new function here.
 
 When a class definition is left normally (via the end), a \emph{class
 object} is created.  This is basically a wrapper around the contents
-of the name space created by the class definition; we'll learn more
+of the namespace created by the class definition; we'll learn more
 about class objects in the next section.  The original local scope
 (the one in effect just before the class definitions was entered) is
 reinstated, and the class object is bound here to the class name given
@@ -3387,7 +3387,7 @@ \subsection{Class Objects \label{classObjects}}
 
 \emph{Attribute references} use the standard syntax used for all
 attribute references in Python: \code{obj.name}.  Valid attribute
-names are all the names that were in the class's name space when the
+names are all the names that were in the class's namespace when the
 class object was created.  So, if the class definition looked like
 this:
 
@@ -3766,9 +3766,10 @@ \section{Private Variables \label{private}}
 when referencing \code{__dict__} directly.
 
 Here's an example of a class that implements its own
-\code{__getattr__} and \code{__setattr__} methods and stores all
-attributes in a private variable, in a way that works in Python 1.4 as
-well as in previous versions:
+\method{__getattr__()} and \method{__setattr__()} methods and stores
+all attributes in a private variable, in a way that works in all
+versions of Python, including those available before this feature was
+added:
 
 \begin{verbatim}
 class VirtualAttributes:
