Modifications du logiciel

C'est le problème fondamental dont tout cela traite. Le logiciel est en constante évolution. C'est doux après tout. Lorsque vous écrivez du code aujourd'hui et que vous l'exécutez, il se comporte d'une certaine manière. La semaine prochaine, vous déciderez que vous n'aimez pas ce qu'il fait et qu'il a besoin de quelques changements. Vous le modifiez et l'exécutez, et il se comporte différemment maintenant. Si vous suiviez un flux de travail de publication approprié, vous étiqueteriez votre logiciel avec des numéros de version et vous auriez maintenant produit deux versions différentes de votre logiciel.

Python n'est également qu'un logiciel, écrit par des personnes qui ne sont que des programmeurs. L'impact des changements dans le langage Python est évidemment un peu différent de celui de changer votre petite application que vous n'exécutez que vous-même. Si les développeurs Python décidaient demain que la prochaine version de Python nécessitait des points-virgules à la fin de chaque ligne pour ressembler davantage à d'autres langages, il faudrait des milliers et des milliers de développeurs de logiciels pour réécrire des millions et des millions de lignes de code pour le rendre compatible avec cette nouvelle version de Python. De toute évidence, ce serait insensé, donc les développeurs Python n'apporteront pas de changements aussi radicaux et assureront une rétrocompatibilité raisonnable avec le code existant.

Pourquoi des changements?

Alors, pourquoi changer quoi que ce soit? Pourquoi ne pouvons-nous pas simplement conserver la version actuelle de Python et la version actuelle de notre code et continuer à l'exécuter pour toujours tel quel? Eh bien, vous pourriez . C'est une stratégie parfaitement fine, dans certaines limites. Il existe trois catégories principales de modifications, qui se reflètent dans le schéma de gestion des versions de Python:

• Changements de version de XYZ: lorsque la version 3.7.1 de Python est mise à jour vers 3.7.2, c'est parce que des bogues ont été trouvés dans 3.7.1 qui nécessitaient une correction. Il s'agit souvent de correctifs de sécurité. Le code existant doit continuer à fonctionner tel quel, à moins qu'il n'ait été directement affecté par le bogue en question. Vous devez toujours garder votre version Python en production à jour avec la dernière version du correctif, pour vous assurer que vous ne tombez pas à cause des vulnérabilités de sécurité.
• Changements de version XY: lorsque Python publie une nouvelle version comme 3.8, c'est pour introduire de nouvelles fonctionnalités. Vous voudrez passer à cette version si vous souhaitez utiliser ces nouvelles fonctionnalités, car elles facilitent votre travail ou votre code plus agréable. Ces versions introduisent aussi parfois des changements de rupture , par exemple la suppression de fonctions obsolètes ou la modification de fonctions existantes de manière mineure. Pendant que vous mettez à jour consciemment vers cette nouvelle version en raison de nouvelles fonctionnalités, vous pouvez également vérifier si vous pourriez être affecté par des modifications importantes et corriger votre code en conséquence.
• Changements de version X. Cela s'apparente généralement à une langue entièrement nouvelle, ce qui se produit très rarement. Python 3 a introduit de nombreuses modifications par rapport à Python 2, ce qui a rendu beaucoup de code tout simplement incompatible et a nécessité une réécriture parfois importante du code existant. En guise d'avantage, Python 3 contenait des améliorations significatives qui rendaient le changement intéressant.

Il y a des pages entières dans la documentation consacrées à ces changements, et vous devriez les parcourir de temps en temps, et surtout avant toute mise à jour majeure: https://docs.python.org/3/whatsnew/index.html

Il existe donc diverses incitations à suivre les changements dans le langage Python, bien qu'ils soient tous facultatifs. Si vous voulez rester sur une version spécifique de Python pour toujours et à jamais, vous le pouvez. Jusqu'à ce que vous ayez besoin de remplacer le matériel sur lequel il fonctionne et que vous constatiez que cette version n'est pas compatible avec votre nouveau matériel de remplacement…

Compatibilité

Il existe différents problèmes de compatibilité. Lorsque de nouvelles fonctionnalités sont introduites, cela introduit une version minimale requise pour tout code utilisant cette fonctionnalité. Par exemple, ce code:

from __future__ import annotations

Cela utilise des chaînes f, une fonctionnalité syntaxique introduite dans Python 3.6. Si vous écrivez ce code, vous avez besoin d'au moins Python 3.6 pour l'exécuter. Python 3.5 refuse d'exécuter ce code, car il n'a aucune idée de ce que sont les f-strings. Cependant, ce type de changement n'a aucun problème de compatibilité ascendante . La syntaxe f'' est simplement une erreur de syntaxe dans les anciennes versions de Python et ne fonctionne tout simplement pas.

Les changements qui fonctionnent sur les anciennes versions de Python, mais se comportent différemment , sont plus préoccupants. Le problème actuel concerne les annotations:

foo: 'bar' = 'baz'

Le comportement de ceci changera subtilement dans Python 3.10. C'est un changement qui a été décidé et qui s'en vient. À partir de Python 3.10, le code ci-dessus se comportera comme:

foo: bar = 'baz'

En d'autres termes, les annotations seront évaluées comme des chaînes et non comme des objets. Pour la plupart des développeurs, cela ne fera que peu de différence et résoudra en fait certains problèmes avec des annotations tels qu'ils fonctionnent aujourd'hui. D'où ce changement. Cependant, en fonction de ce que vous faites avec les annotations, cette modification peut également casser votre code.

Futures

Et ainsi nous arrivons enfin à l'avenir: vous pouvez opter pour le nouveau comportement des annotations aujourd'hui si vous utilisez au moins Python 3.7 en important le futur approprié:

print(f'foo {bar} baz')

Si vous faites cela dans votre code, votre code évaluera déjà les annotations comme des chaînes aujourd'hui. Ce comportement deviendra par défaut dans Python 3.10. En d'autres termes, ce changement a été implémenté dans Python 3.7, mais est facultatif et opt-in. Il deviendra obligatoire en 3.10. À ce stade, à from __future__ import annotations ne feront tout simplement rien; que vous le spécifiez ou non, votre code se comportera dans un sens et dans un seul.

Cela donne aux développeurs trois versions principales, ou environ trois ans, pour mettre à jour leur code s'ils en ont besoin. De cette façon, personne ne sera surpris par la rupture de leur code si et quand ils essaient d'exécuter leur code existant sur Python 3.10 un jour. (À moins qu'ils n'aient vécu sous un rocher ces dernières années, et qu'il y aura des gens comme ça, malheureusement. Mais l'impact sera grandement minimisé.)

C'est donc à cela que sert l'avenir. Ils implémentent des changements de rupture, mais cachent ces changements derrière une import opt-in explicite, afin de permettre une fenêtre glissante dans laquelle les développeurs peuvent mettre à jour leur code afin de ne pas obliger des milliers de développeurs à réécrire leur code en panique lorsqu'ils ' sont soudainement confrontés à des codes de rupture en production car leur version de production Python a été mise à niveau pour une raison ou une autre.

Et ce n'est pas seulement une relation directe entre les développeurs Python et les codeurs comme vous; vous dépendez souvent de bibliothèques tierces, et celles-ci devront également être mises à jour. Chaque modification apportée au langage Python a un lent effet de retombée de Python vers les développeurs de bibliothèques, les mainteneurs de référentiel et les codeurs comme vous. Cela demande simplement du temps et les contrats à terme achètent ce genre de temps.

Il y a eu une tonne de ces types de changements au cours des années où Python était en train de passer de Python 2 à Python 3, et bon nombre des changements de rupture introduits dans Python 3 pourraient lentement être transposés avec l'utilisation de futurs. Au moment de la rédaction de cet article, il n'y a que le changement d'annotations susmentionné qui est actuellement une préoccupation active. Mais cela n'empêche pas Python d'introduire d'autres changements nouveaux et révolutionnaires qui seront déployés dans le futur dans ... le futur.

Les points que vous citez dans la documentation que vous ne comprenez pas ne sont pas très importants et ne sont que des détails de mise en œuvre interne. En un mot, même si les contrats à terme optent pour l'utilisation from ... import ... déclarations from ... import ... , ce ne sont pas de véritables importations de modules. Ce sont des indicateurs de compilateur qui semblent juste importer un module réel. (Une importation de module réelle n'aurait pas le genre de pouvoir pour apporter les changements que ces futurs modifient réellement.) Ce que vous citez dans la documentation est simplement d'expliquer que, comme il ne s'agit pas d'importations réelles, certains outils peuvent devenir confus s'ils essayez de les traiter comme des importations de modules réelles. Dans ce seul but, il existe un module « __future__ valide, et cette documentation que vous citez est à peu près cela et explique pourquoi il existe même quand il n'a aucun effet réel.

Utilisez __future__ lorsque vous souhaitez être proactif dans la modernisation de votre code.

Dans de nombreux cas, vous vous surprendrez à l'utiliser lorsque vous jugerez qu'une nouvelle fonctionnalité en vaut la peine pour votre projet, mais vous devez toujours prendre en charge les anciennes versions de Python.

Cependant, vous pouvez également l'utiliser pour réduire votre dette technologique en cas de modifications futures et éviter les fractionnements de version dans votre projet.

Quel est l'intérêt de __future__ ?

__future__ permet d'introduire un nouveau comportement dans le langage qui serait rétrocompatible . Par exemple, dans Python 2.2 - 2.7, vous pouvez faire:

+----------------|---------------|----------------+
|    feature     | __future__ in | implemented in |
|----------------|---------------|----------------|
|----------------|---------------|----------------|
| generator_stop |      3.5      |      3.7       |
|----------------|---------------|----------------|
|  annotations   |      3.7      |      3.10      |
+----------------|---------------+----------------+

__future__ signifie "nous avons ajouté cette fonctionnalité dans le langage, mais nous ne pouvons pas en faire la valeur par défaut car cela briserait un autre code".

Pourquoi __future__ a-t-il été introduit à l'origine?

Supposons que vous ayez un projet Python 2 et que vous souhaitiez le faire passer à Python 3. Plutôt que de le convertir en un «big bang» et en espérant qu'il se comporte toujours de la même manière sous Python 3, les développeurs peuvent mettre à niveau leur projet pièce par pièce , en important d'abord la division par exemple et en testant les régressions, puis en important print_function et ainsi de suite.

À quoi sert __future__ dans Python 3?

Une version "Python 4" n'est pas à l'horizon . Mais deux fonctionnalités ont déjà été ajoutées à Python 3 de cette façon:

>>> 3/2
1
>>> from __future__ import division
>>> 3/2
1.5

Ces deux changements étaient incompatibles avec les versions antérieures . Cela signifie que les responsables du langage ont apporté un grand changement au fonctionnement des générateurs qui était prêt pour la version 3.5. Cependant, ils l'ont "caché" dans le module __future__ , car ils craignaient qu'un tas de paquets ne se brise lors de la sortie de 3.5 s'ils le sortaient directement.

Il y a toujours des changements plus petits et incompatibles avec Python, par exemple l'introduction des mots-clés async et await dans la version 3.7, ce qui rend le code qui les utilisait comme noms de variables ( async = 1 ) cassé. C'est vraiment un appel au jugement pour savoir s'il faut introduire une fonctionnalité directement ou en tant que __future__ , en fonction de l'effort d'une migration.

Ainsi, le mettre dans un __future__ avec un DeprecationWarning permet une période de transition pour les mainteneurs, ce qui permet d' activer la fonctionnalité plus tôt.