Jeremy Hylton | e41195f | 2003-05-21 21:45:01 +0000 | [diff] [blame] | 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 | |
Raymond Hettinger | 02771c1 | 2003-08-05 11:40:21 +0000 | [diff] [blame] | 26 | Each statement in \file{__future__.py} is of the form: |
Jeremy Hylton | e41195f | 2003-05-21 21:45:01 +0000 | [diff] [blame] | 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 | |