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

Skip to content

Commit e41195f

Browse files
committed
Add documentation for __future__
1 parent 8bea5dc commit e41195f

1 file changed

Lines changed: 69 additions & 0 deletions

File tree

Doc/lib/lib__future__.tex

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
\section{\module{__future__} ---
2+
Future statement definitions}
3+
4+
\declaremodule[future]{standard}{__future__}
5+
\modulesynopsis{Future statement definitions}
6+
7+
\module{__future__} is a real module, and serves three purposes:
8+
9+
\begin{itemize}
10+
11+
\item To avoid confusing existing tools that analyze import statements
12+
and expect to find the modules they're importing.
13+
14+
\item To ensure that future_statements run under releases prior to 2.1
15+
at least yield runtime exceptions (the import of
16+
\module{__future__} will fail, because there was no module of
17+
that name prior to 2.1).
18+
19+
\item To document when incompatible changes were introduced, and when they
20+
will be --- or were --- made mandatory. This is a form of executable
21+
documentation, and can be inspected programatically via importing
22+
\module{__future__} and examining its contents.
23+
24+
\end{itemize}
25+
26+
Each statment in \file{__future__.py} is of the form:
27+
28+
\begin{verbatim}
29+
FeatureName = "_Feature(" OptionalRelease "," MandatoryRelease ","
30+
CompilerFlag ")"
31+
\end{verbatim}
32+
33+
where, normally, OptionalRelease is less then MandatoryRelease, and
34+
both are 5-tuples of the same form as \code{sys.version_info}:
35+
36+
\begin{verbatim}
37+
(PY_MAJOR_VERSION, # the 2 in 2.1.0a3; an int
38+
PY_MINOR_VERSION, # the 1; an int
39+
PY_MICRO_VERSION, # the 0; an int
40+
PY_RELEASE_LEVEL, # "alpha", "beta", "candidate" or "final"; string
41+
PY_RELEASE_SERIAL # the 3; an int
42+
)
43+
\end{verbatim}
44+
45+
OptionalRelease records the first release in which the feature was
46+
accepted.
47+
48+
In the case of MandatoryReleases that have not yet occurred,
49+
MandatoryRelease predicts the release in which the feature will become
50+
part of the language.
51+
52+
Else MandatoryRelease records when the feature became part of the
53+
language; in releases at or after that, modules no longer need a
54+
future statement to use the feature in question, but may continue to
55+
use such imports.
56+
57+
MandatoryRelease may also be \code{None}, meaning that a planned
58+
feature got dropped.
59+
60+
Instances of class \class{_Feature} have two corresponding methods,
61+
\method{getOptionalRelease()} and \method{getMandatoryRelease()}.
62+
63+
CompilerFlag is the (bitfield) flag that should be passed in the
64+
fourth argument to the builtin function \function{compile()} to enable
65+
the feature in dynamically compiled code. This flag is stored in the
66+
\member{compiler_flag} attribute on \class{_Future} instances.
67+
68+
No feature description will ever be deleted from \module{__future__}.
69+

0 commit comments

Comments
 (0)