gh-110893: Improve docs for __future__ module

Doc/library/__future__.rst

@@ -8,19 +8,24 @@
 
 --------------
 
-: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 :ref:`future statements <future>` 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.
+To use a specific feature, import it from the :mod:`__future__` module using
+the syntax ``from __future__ import <feature>``. It is important to note that
+the ``__future__ import`` statement must be placed as the first statement in
+the source file, except for a module docstring.
+
+If a feature has been imported, the ``__future__ import`` remains valid even
+after the *MandatoryRelease* version. However, it has no behavioural effect.
+code will be compatible with multiple versions during the transition phase of
+a feature. If code only supports versions greater than or equal to the
+*MandatoryRelease* version, then no longer need the ``__future__ import`` for
+that specific feature.
+
+Once a feature has been imported, :ref:`future<future>` import remains valid
+even after the *MandatoryRelease* version. However, it has no behavioral effect.
+So this code will be compatible with multiple versions during the transition
+phase of a feature. If code only supports versions greater than or equal to
+the *MandatoryRelease* version, then no longer need to include the
+:mod:`__future__` import for that specific feature.
 
 .. _future-classes:
 
@@ -35,35 +40,33 @@
    5-tuples of the same form as :data:`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
+      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
       )
 
+The release information for features is captured through *OptionalRelease* and
+*MandatoryRelease*. The *OptionalRelease* records the first release in which the
+feature was accepted, *MandatoryRelease* records when the feature became part
+of the language. Once a feature is included in a *MandatoryRelease*, modules no
+longer need a future statement to use the feature, but they may continue to use
+such imports if needed.
+
 .. method:: _Feature.getOptionalRelease()
 
-   *OptionalRelease* records the first release in which the feature was accepted.
+   This method returns the release information for the OptionalRelease of a feature.
 
 .. method:: _Feature.getMandatoryRelease()
 
-   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 or that it is not yet decided.
+   This method returns the release information for the MandatoryRelease of a feature.
 
 .. attribute:: _Feature.compiler_flag
 
-   *CompilerFlag* is the (bitfield) flag that should be passed in the fourth
-   argument to the built-in function :func:`compile` to enable the feature in
-   dynamically compiled code.  This flag is stored in the :attr:`_Feature.compiler_flag`
-   attribute on :class:`_Feature` instances.
+   The *CompilerFlag* is a bitfield flag that should be passed in the fourth
+   argument to the built-in function :func:`compile` in order to enable the
+   feature in dynamically compiled code. This flag is stored in the
+   :attr:`_Feature.compiler_flag` attribute on :class:`_Feature` instances.
 
 No feature description will ever be deleted from :mod:`__future__`. Since its
 introduction in Python 2.1 the following features have found their way into the