mirror of
https://github.com/python/cpython.git
synced 2024-12-02 14:24:12 +08:00
ff2ad0e1a6
svn+ssh://pythondev@svn.python.org/python/trunk ........ r71814 | georg.brandl | 2009-04-23 10:44:57 +0200 (Do, 23 Apr 2009) | 1 line #5820: fix bug in usage of getreader(). ........ r71815 | georg.brandl | 2009-04-23 10:49:39 +0200 (Do, 23 Apr 2009) | 1 line Fix rewrapping accident. ........ r71816 | georg.brandl | 2009-04-23 10:49:56 +0200 (Do, 23 Apr 2009) | 1 line #5813: add a reference to the "future statements" section. ........ r71817 | georg.brandl | 2009-04-23 10:52:03 +0200 (Do, 23 Apr 2009) | 1 line Add link to PEP 236. ........ r71901 | georg.brandl | 2009-04-25 16:50:25 +0200 (Sa, 25 Apr 2009) | 1 line #3320: fix spelling. ........ r71902 | georg.brandl | 2009-04-25 16:51:31 +0200 (Sa, 25 Apr 2009) | 1 line #5834: use "failure" instead of "error" because the two have different meanings in unittest context. ........ r71903 | georg.brandl | 2009-04-25 17:05:04 +0200 (Sa, 25 Apr 2009) | 1 line #5821: add some capabilities of TarFile's file-like object. ........
65 lines
2.4 KiB
ReStructuredText
65 lines
2.4 KiB
ReStructuredText
:mod:`__future__` --- Future statement definitions
|
|
==================================================
|
|
|
|
.. module:: __future__
|
|
:synopsis: Future statement definitions
|
|
|
|
|
|
:mod:`__future__` is a real module, and serves three purposes:
|
|
|
|
* To avoid confusing existing tools that analyze import statements and expect to
|
|
find the modules they're importing.
|
|
|
|
* To ensure that future_statements run under releases prior to 2.1 at least
|
|
yield runtime exceptions (the import of :mod:`__future__` will fail, because
|
|
there was no module of that name prior to 2.1).
|
|
|
|
* To document when incompatible changes were introduced, and when they will be
|
|
--- or were --- made mandatory. This is a form of executable documentation, and
|
|
can be inspected programmatically via importing :mod:`__future__` and examining
|
|
its contents.
|
|
|
|
Each statement in :file:`__future__.py` is of the form::
|
|
|
|
FeatureName = _Feature(OptionalRelease, MandatoryRelease,
|
|
CompilerFlag)
|
|
|
|
|
|
where, normally, *OptionalRelease* is less than *MandatoryRelease*, and both are
|
|
5-tuples of the same form as ``sys.version_info``::
|
|
|
|
(PY_MAJOR_VERSION, # the 2 in 2.1.0a3; an int
|
|
PY_MINOR_VERSION, # the 1; an int
|
|
PY_MICRO_VERSION, # the 0; an int
|
|
PY_RELEASE_LEVEL, # "alpha", "beta", "candidate" or "final"; string
|
|
PY_RELEASE_SERIAL # the 3; an int
|
|
)
|
|
|
|
*OptionalRelease* records the first release in which the feature was accepted.
|
|
|
|
In the case of a *MandatoryRelease* that has not yet occurred,
|
|
*MandatoryRelease* predicts the release in which the feature will become part of
|
|
the language.
|
|
|
|
Else *MandatoryRelease* records when the feature became part of the language; in
|
|
releases at or after that, modules no longer need a future statement to use the
|
|
feature in question, but may continue to use such imports.
|
|
|
|
*MandatoryRelease* may also be ``None``, meaning that a planned feature got
|
|
dropped.
|
|
|
|
Instances of class :class:`_Feature` have two corresponding methods,
|
|
:meth:`getOptionalRelease` and :meth:`getMandatoryRelease`.
|
|
|
|
*CompilerFlag* is the (bitfield) flag that should be passed in the fourth
|
|
argument to the builtin function :func:`compile` to enable the feature in
|
|
dynamically compiled code. This flag is stored in the :attr:`compiler_flag`
|
|
attribute on :class:`_Feature` instances.
|
|
|
|
No feature description will ever be deleted from :mod:`__future__`.
|
|
|
|
.. seealso::
|
|
|
|
:ref:`future`
|
|
How the compiler treats future imports.
|