|
| 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