"__future__" — Définitions des futurs
*************************************

**Source code:** Lib/_future_.py

======================================================================

Le module "__future__" est un vrai module, et il a trois objectifs :

* éviter de dérouter les outils existants qui analysent les
  instructions d'importation et s'attendent à trouver les modules
  qu'ils importent ;

* s'assurer que les instructions *future* lancées sous les versions
  antérieures à 2.1 lèvent au moins des exceptions à l'exécution
  (l’importation du module "__future__" échoue, car il n’y avait pas
  de module de ce nom avant 2.1) ;

* Pour documenter le phasage de changements entraînant des
  incompatibilités : introduction, utilisation obligatoire. Il s’agit
  d’une forme de documentation exécutable, qui peut être inspectée par
  un programme en important "__future__" et en examinant son contenu.

Chaque instruction dans "__future__.py" est de la forme :

   FeatureName = _Feature(OptionalRelease, MandatoryRelease,
                          CompilerFlag)

où, normalement, *OptionalRelease* est inférieur à *MandatoryRelease*,
et les deux sont des quintuplets de la même forme que
"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* enregistre la première version dans laquelle la
fonctionnalité a été acceptée.

Dans le cas d'un *MandatoryRelease* qui n'a pas encore eu lieu,
*MandatoryRelease* prédit la *release* dans laquelle la fonctionnalité
deviendra un élément du langage.

Sinon *MandatoryRelease* enregistre lorsque la fonctionnalité est
devenue une partie du langage ; dans cette version ou les suivantes,
les modules n'ont plus besoin d'une déclaration *future* pour utiliser
la fonctionnalité en question, mais ils peuvent continuer à utiliser
ces importations.

*MandatoryRelease* peut également être "None", ce qui signifie qu'une
fonction planifiée a été abandonnée.

Les instances de classe "_Feature" ont deux méthodes correspondantes,
"getOptionalRelease()" et "getMandatoryRelease()".

*CompilerFlag* est un drapeau (chaque bit représente un champ) qui
doit être passé en tant que quatrième argument à la fonction native
"compile()" pour activer la fonctionnalité dans le code compilé
dynamiquement. Cet indicateur est stocké dans l'attribut
"compiler_flag" dans les instances de "_Feature".

Aucune fonctionnalité ne sera jamais supprimée de "__future__". Depuis
son introduction dans Python 2.1, les fonctionnalités suivantes ont
trouvé leur places dans le langage utilisant ce mécanisme :

+--------------------+---------------+----------------+-----------------------------------------------+
| fonctionnalité     | optionnel     | obligatoire    | effet                                         |
|                    | dans          | dans           |                                               |
|====================|===============|================|===============================================|
| nested_scopes      | 2.1.0b1       | 2.2            | **PEP 227** : *Portées imbriquées*            |
+--------------------+---------------+----------------+-----------------------------------------------+
| générateurs        | 2.2.0a1       | 2.3            | **PEP 255** : *Générateurs simples*           |
+--------------------+---------------+----------------+-----------------------------------------------+
| division           | 2.2.0a2       | 3.0            | **PEP 238** : *Changement de l'opérateur de   |
|                    |               |                | division*                                     |
+--------------------+---------------+----------------+-----------------------------------------------+
| absolute_import    | 2.5.0a1       | 3.0            | **PEP 328** : *Importations : multilignes et  |
|                    |               |                | absolues/relatives* (ressource en anglais)    |
+--------------------+---------------+----------------+-----------------------------------------------+
| with_statement     | 2.5.0a1       | 2.6            | **PEP 343** : *L'instruction "with"*          |
+--------------------+---------------+----------------+-----------------------------------------------+
| print_function     | 2.6.0a2       | 3.0            | **PEP 3105** : *Transformation de print en    |
|                    |               |                | fonction*                                     |
+--------------------+---------------+----------------+-----------------------------------------------+
| unicode_literals   | 2.6.0a2       | 3.0            | **PEP 3112** : *Chaînes d'octets littéraux en |
|                    |               |                | Python 3000*                                  |
+--------------------+---------------+----------------+-----------------------------------------------+
| generator_stop     | 3.5.0b1       | 3.7            | **PEP 479** : *Gestion de *StopIteration* à   |
|                    |               |                | l’intérieur des générateurs*                  |
+--------------------+---------------+----------------+-----------------------------------------------+
| annotations        | 3.7.0b1       | TBD [1]        | **PEP 563** : *Évaluation différée des        |
|                    |               |                | annotations*                                  |
+--------------------+---------------+----------------+-----------------------------------------------+

[1] "from __future__ import annotations" was previously scheduled to
    become mandatory in Python 3.10, but the Python Steering Council
    twice decided to delay the change (announcement for Python 3.10;
    announcement for Python 3.11). No final decision has been made
    yet. See also **PEP 563** and **PEP 649**.

Voir aussi:

  L'instruction future
     Comment le compilateur gère les importations « futures ».
