mirror of
https://github.com/python/cpython.git
synced 2025-12-04 00:30:19 +00:00
When referring to namespaces, always say "namespaces" instead of
"name spaces". Inconsistency noted by Keith Briggs <keith.briggs@bt.com>.
This commit is contained in:
parent
81cccb7563
commit
1349437e4c
4 changed files with 54 additions and 53 deletions
|
|
@ -3242,18 +3242,18 @@ subject is useful for any advanced Python programmer.
|
||||||
|
|
||||||
Let's begin with some definitions.
|
Let's begin with some definitions.
|
||||||
|
|
||||||
A \emph{name space} is a mapping from names to objects. Most name
|
A \emph{namespace} is a mapping from names to objects. Most
|
||||||
spaces are currently implemented as Python dictionaries, but that's
|
namespaces are currently implemented as Python dictionaries, but
|
||||||
normally not noticeable in any way (except for performance), and it
|
that's normally not noticeable in any way (except for performance),
|
||||||
may change in the future. Examples of name spaces are: the set of
|
and it may change in the future. Examples of namespaces are: the set
|
||||||
built-in names (functions such as \function{abs()}, and built-in exception
|
of built-in names (functions such as \function{abs()}, and built-in
|
||||||
names); the global names in a module; and the local names in a
|
exception names); the global names in a module; and the local names in
|
||||||
function invocation. In a sense the set of attributes of an object
|
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
|
also form a namespace. The important thing to know about namespaces
|
||||||
spaces is that there is absolutely no relation between names in
|
is that there is absolutely no relation between names in different
|
||||||
different name spaces; for instance, two different modules may both
|
namespaces; for instance, two different modules may both define a
|
||||||
define a function ``maximize'' without confusion --- users of the
|
function ``maximize'' without confusion --- users of the modules must
|
||||||
modules must prefix it with the module name.
|
prefix it with the module name.
|
||||||
|
|
||||||
By the way, I use the word \emph{attribute} for any name following a
|
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
|
dot --- for example, in the expression \code{z.real}, \code{real} is
|
||||||
|
|
@ -3262,12 +3262,12 @@ names in modules are attribute references: in the expression
|
||||||
\code{modname.funcname}, \code{modname} is a module object and
|
\code{modname.funcname}, \code{modname} is a module object and
|
||||||
\code{funcname} is an attribute of it. In this case there happens to
|
\code{funcname} is an attribute of it. In this case there happens to
|
||||||
be a straightforward mapping between the module's attributes and the
|
be a straightforward mapping between the module's attributes and the
|
||||||
global names defined in the module: they share the same name
|
global names defined in the module: they share the same namespace!
|
||||||
space!\footnote{
|
\footnote{
|
||||||
Except for one thing. Module objects have a secret read-only
|
Except for one thing. Module objects have a secret read-only
|
||||||
attribute called \code{__dict__} which returns the dictionary
|
attribute called \member{__dict__} which returns the dictionary
|
||||||
used to implement the module's namespace; the name
|
used to implement the module's namespace; the name
|
||||||
\code{__dict__} is an attribute but not a global name.
|
\member{__dict__} is an attribute but not a global name.
|
||||||
Obviously, using this violates the abstraction of namespace
|
Obviously, using this violates the abstraction of namespace
|
||||||
implementation, and should be restricted to things like
|
implementation, and should be restricted to things like
|
||||||
post-mortem debuggers.
|
post-mortem debuggers.
|
||||||
|
|
@ -3297,10 +3297,10 @@ that is not handled within the function. (Actually, forgetting would
|
||||||
be a better way to describe what actually happens.) Of course,
|
be a better way to describe what actually happens.) Of course,
|
||||||
recursive invocations each have their own local namespace.
|
recursive invocations each have their own local namespace.
|
||||||
|
|
||||||
A \emph{scope} is a textual region of a Python program where a name space
|
A \emph{scope} is a textual region of a Python program where a
|
||||||
is directly accessible. ``Directly accessible'' here means that an
|
namespace is directly accessible. ``Directly accessible'' here means
|
||||||
unqualified reference to a name attempts to find the name in the name
|
that an unqualified reference to a name attempts to find the name in
|
||||||
space.
|
the namespace.
|
||||||
|
|
||||||
Although scopes are determined statically, they are used dynamically.
|
Although scopes are determined statically, they are used dynamically.
|
||||||
At any time during execution, exactly three nested scopes are in use
|
At any time during execution, exactly three nested scopes are in use
|
||||||
|
|
@ -3316,13 +3316,13 @@ the same name space as the global scope: the module's name space.
|
||||||
Class definitions place yet another namespace in the local scope.
|
Class definitions place yet another namespace in the local scope.
|
||||||
|
|
||||||
It is important to realize that scopes are determined textually: the
|
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
|
global scope of a function defined in a module is that module's
|
||||||
space, no matter from where or by what alias the function is called.
|
namespace, no matter from where or by what alias the function is
|
||||||
On the other hand, the actual search for names is done dynamically, at
|
called. On the other hand, the actual search for names is done
|
||||||
run time --- however, the language definition is evolving towards
|
dynamically, at run time --- however, the language definition is
|
||||||
static name resolution, at ``compile'' time, so don't rely on dynamic
|
evolving towards static name resolution, at ``compile'' time, so don't
|
||||||
name resolution! (In fact, local variables are already determined
|
rely on dynamic name resolution! (In fact, local variables are
|
||||||
statically.)
|
already determined statically.)
|
||||||
|
|
||||||
A special quirk of Python is that assignments always go into the
|
A special quirk of Python is that assignments always go into the
|
||||||
innermost scope. Assignments do not copy data --- they just
|
innermost scope. Assignments do not copy data --- they just
|
||||||
|
|
@ -3766,9 +3766,10 @@ code that is byte-compiled together. The same restriction applies to
|
||||||
when referencing \code{__dict__} directly.
|
when referencing \code{__dict__} directly.
|
||||||
|
|
||||||
Here's an example of a class that implements its own
|
Here's an example of a class that implements its own
|
||||||
\code{__getattr__} and \code{__setattr__} methods and stores all
|
\method{__getattr__()} and \method{__setattr__()} methods and stores
|
||||||
attributes in a private variable, in a way that works in Python 1.4 as
|
all attributes in a private variable, in a way that works in all
|
||||||
well as in previous versions:
|
versions of Python, including those available before this feature was
|
||||||
|
added:
|
||||||
|
|
||||||
\begin{verbatim}
|
\begin{verbatim}
|
||||||
class VirtualAttributes:
|
class VirtualAttributes:
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue