Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 324cc6e

Browse files
jeremyhyltonjeremyhylton
committed
Add some initial text for the appendix on future statements and nested scopes.
1 parent 2c84fc8 commit 324cc6e

1 file changed

Lines changed: 149 additions & 0 deletions

File tree

‎Doc/ref/refa1.tex‎

Lines changed: 149 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,149 @@
1+
\chapter{Appendix: Future statements and nested scopes}
2+
3+
The semantics of Python's static scoping will change in version 2.2 to
4+
support resolution of unbound local names in enclosing functions'
5+
namespaces. The new semantics will be available in Python 2.1 through
6+
the use of a future statement. This appendix documents these two
7+
features for Python 2.1; it will be removed in Python 2.2 and the
8+
features will be documented in the main sections of this manual.
9+
10+
\section{Future statements}
11+
\indexii{future}{statement}
12+
13+
A \dfn{future statement} is a directive to the compiler that a
14+
particular module should be compiled using syntax or semantics that
15+
will be available in a specified future release of Python. The future
16+
statement is intended to ease migration to future versions of Python
17+
that introduce incompatible changes to the language. It allows use of
18+
the new features on a per-module basis before the release in which the
19+
feature becomes standard.
20+
21+
\begin{verbatim}
22+
future_statement: "from" "__future__" "import" feature ["as" name]
23+
("," feature ["as" name])*
24+
25+
feature: identifier
26+
name: identifier
27+
\end{verbatim}
28+
29+
A future statement must appear near the top of the module. The only
30+
lines that can appear before a future statement are:
31+
32+
\begin{itemize}
33+
34+
\item the module docstring (if any),
35+
\item comments,
36+
\item blank lines, and
37+
\item other future statements.
38+
39+
\end{itemize}
40+
41+
The only feature recognized by Python 2.1 is \samp{nested_scopes}.
42+
43+
A future statement is recognized and treated specially at compile time:
44+
Changes to the semantics of core constructs are often implemented by
45+
generating different code. It may even be the case that a new feature
46+
introduces new incompatible syntax (such as a new reserved word), in
47+
which case the compiler may need to parse the module differently. Such
48+
decisions cannot be pushed off until runtime.
49+
50+
For any given release, the compiler knows which feature names have been
51+
defined, and raises a compile-time error if a future statement contains
52+
a feature not known to it.
53+
54+
The direct runtime semantics are the same as for any import statement:
55+
there is a standard module \file{__future__.py}, described later, and
56+
it will be imported in the usual way at the time the future statement
57+
is executed.
58+
59+
The interesting runtime semantics depend on the specific feature
60+
enabled by the future statement.
61+
62+
Note that there is nothing special about the statement:
63+
64+
\begin{verbatim}
65+
import __future__ [as name]
66+
\end{verbatim}
67+
68+
That is not a future statement; it's an ordinary import statement, with
69+
no special semantics or syntax restrictions.
70+
71+
Code compiled by an exec statement or calls to the builtin functions
72+
\function{compile} and \function{execfile} that occur in a module M
73+
containing a future statement will use the new syntax or semantics
74+
associated with the future statement.
75+
76+
A future statement typed at an interactive interpreter prompt will
77+
take effect for the rest of the interpreter session. If an
78+
interpreter is started with the \emph{-i} option, is passed a
79+
script name to execute, and the script includes a future statement, it
80+
will be in effect in the interactive session started after the script
81+
is executed.
82+
83+
\section{\module{__future__} ---
84+
Future statement definitions}
85+
86+
\declaremodule{standard}{__future__}
87+
\modulesynopsis{Future statement definitions}
88+
89+
\file{__future__.py} is a real module, and serves three purposes:
90+
91+
\begin{itemize}
92+
93+
\item To avoid confusing existing tools that analyze import statements
94+
and expect to find the modules they're importing.
95+
96+
\item To ensure that future_statements run under releases prior to 2.1
97+
at least yield runtime exceptions (the import of
98+
\code{__future__} will fail, because there was no module of
99+
that name prior to 2.1).
100+
101+
\item To document when incompatible changes were introduced, and when they
102+
will be --- or were --- made mandatory. This is a form of executable
103+
documentation, and can be inspected programatically via importing
104+
\code{__future__} and examining its contents.
105+
106+
\end{itemize}
107+
108+
Each statment in \file{__future__.py} is of the form:
109+
110+
\begin{verbatim}
111+
FeatureName = "_Feature(" OptionalRelease "," MandatoryRelease ")"
112+
\end{verbatim}
113+
114+
where, normally, OptionalRelease < MandatoryRelease, and both are
115+
5-tuples of the same form as \code{sys.version_info}:
116+
117+
\begin{verbatim}
118+
(PY_MAJOR_VERSION, # the 2 in 2.1.0a3; an int
119+
PY_MINOR_VERSION, # the 1; an int
120+
PY_MICRO_VERSION, # the 0; an int
121+
PY_RELEASE_LEVEL, # "alpha", "beta", "candidate" or "final"; string
122+
PY_RELEASE_SERIAL # the 3; an int
123+
)
124+
\end{verbatim}
125+
126+
OptionalRelease records the first release in which the feature was
127+
accepted.
128+
129+
In the case of MandatoryReleases that have not yet occurred,
130+
MandatoryRelease predicts the release in which the feature will become
131+
part of the language.
132+
133+
Else MandatoryRelease records when the feature became part of the
134+
language; in releases at or after that, modules no longer need a
135+
future statement to use the feature in question, but may continue to
136+
use such imports.
137+
138+
MandatoryRelease may also be None, meaning that a planned feature got
139+
dropped.
140+
141+
Instances of class \class{_Feature} have two corresponding methods,
142+
\member{getOptionalRelease()} and \member{getMandatoryRelease()}.
143+
144+
No feature line will ever be deleted from \file{__future__.py}.
145+
146+
\section{Nested scopes}
147+
\indexii{nested}{scopes}
148+
149+
Nested scopes are left as an exercise for the reader.

0 commit comments

Comments
 (0)