Ce document est relatif à une vieille version de Python qui n'est plus soutenue. Mettez à jour votre version et lisez Bienvenue sur la documentation de la version stable actuelle de Python.

# Portage de code Python 2 vers Python 3

auteur

  Brett Cannon

Résumé

Python 3 étant le futur de Python tandis que Python 2 est encore activement utilisé, il est préférable de faire en sorte que votre projet soit disponible pour les deux versions majeures de Python. Ce guide est destiné à vous aider à comprendre comment gérer simultanément Python 2 & 3.

Si vous cherchez à porter un module d'extension plutôt que du pur Python, veuillez consulter Portage des modules d'extension vers Python 3.

Si vous souhaitez lire l'avis d'un développeur principal de Python sur ce qui a motivé la création de Python 3, vous pouvez lire le Python 3 Q & A de Nick Coghlan ou bien Why Python 3 exists de Brett Cannon.

Vous pouvez lire les archives de la liste diffusion python-porting dans vos recherches sur les questions liées au portage.

## La version courte

Afin de rendre votre projet compatible Python 2/3 avec le même code source, les étapes de base sont :

1. Ne se préoccuper que du support de Python 2.7

2. S'assurer d'une bonne couverture des tests (coverage.py peut aider ; `python -m pip install coverage`)

3. Apprendre les différences entre Python 2 et 3

4. Utiliser Futurize (ou Modernize) pour mettre à jour votre code (par exemple `python -m pip install future`)

5. Utilisez Pylint pour vous assurer que vous ne régressez pas sur votre prise en charge de Python 3 (`python -m pip install pylint`)

6. Utiliser caniusepython3 pour déterminer quelles sont, parmi les dépendances que vous utilisez, celles qui bloquent votre utilisation de Python 3 (`python -m pip install caniusepython3`)

7. Une fois que vos dépendances ne sont plus un obstacle, utiliser l'intégration continue pour s'assurer que votre code demeure compatible Python 2 & 3 (tox peut aider à tester la comptabilité de sources avec plusieurs versions de Python; `python -m pip install tox`)

8. Envisager l'utilisation d'un vérifieur de type statique afin de vous assurer que votre façon d'utiliser les types est compatible avec Python 2 et 3 (par exemple en utilisant mypy pour vérifier votre typage sous Python 2 et 3 ; `python -m pip install mypy`).

Note

Note : L'utilisation de `python -m pip install` garantit que le pip invoqué est bien celui installé avec la version de Python que vous utilisez, que ce soit un `pip` du système ou un `pip` installé dans un environnement virtuel.

## Détails

Un point clé du support simultané de Python 2 et 3 est qu'il vous est possible de commencer dès aujourd'hui ! Même si vos dépendances ne sont pas encore compatibles Python 3, vous pouvez moderniser votre code dès maintenant pour gérer Python 3. La plupart des modifications nécessaires à la compatibilité Python 3 donnent un code plus propre utilisant une syntaxe plus récente, même dans du code Python 2.

Un autre point important est que la modernisation de votre code Python 2 pour le rendre compatible Python 3 est pratiquement automatique. Bien qu'il soit possible d'avoir à effectuer des changements d'API compte-tenu de la clarification de la gestion des données textuelles et binaires dans Python 3, le travail de bas niveau est en grande partie fait pour vous et vous pouvez ainsi bénéficiez de ces modifications automatiques immédiatement.

Gardez ces points-clés en tête pendant que vous lisez les détails ci-dessous concernant le portage de votre code vers une compatibilité simultanée Python 2 et 3.

### Abandon de la compatibilité Python 2.6 et antérieures

Bien qu'il soit possible de rendre Python 2.5 compatible avec Python 3, il est beaucoup plus simple de n'avoir qu'à travailler avec Python 2.7. Si abandonner Python 2.5 n'est pas une option, alors le projet six peut vous aider à gérer simultanément Python 2.5 et 3 (`python -m pip install six`). Néanmoins, soyez conscient que la quasi-totalité des projets listés dans ce guide pratique ne seront pas applicables à votre situation.

Si vous pouvez ignorer Python 2.5 et antérieur, les changements nécessaires à appliquer à votre code devraient encore ressembler à vos yeux à du code Python idiomatique. Dans le pire cas, vous devrez utiliser une fonction plutôt qu'une méthode dans certains cas, ou bien vous devrez importer une fonction plutôt qu'utiliser une fonction native, mais le reste du temps le code transformé devrait vous rester familier.

Mais nous vous conseillons de viser seulement un support de Python 2.7. Python 2.6 n'est plus supporté gratuitement et par conséquent ne reçoit plus aucun correctif. Cela signifie que vous devrez trouver des solutions de contournement aux problèmes que vous rencontrez avec Python 2.6. Il existe en outre des outils mentionnés dans ce guide pratique qui ne supportent pas Python 2.6 (par exemple Pylint), ce qui sera de plus en plus courant au fil du temps. Il est simplement plus facile pour vous de n'assurer une compatibilité qu'avec les versions de Python que vous avez l'obligation de gérer.

### Assurez vous de spécifier la bonne version supportée dans le fichier `setup.py`

Votre fichier `setup.py` devrait contenir le bon trove classifier spécifiant les versions de Python avec lesquelles vous êtes compatible. Comme votre projet ne supporte pas encore Python 3, vous devriez au moins spécifier `Programming Language :: Python :: 2 :: Only`. Dans l'idéal vous devriez indiquer chaque version majeure/mineure de Python que vous gérez, par exemple `Programming Language :: Python :: 2.7`.

### Obtenir une bonne couverture de code

Une fois que votre code est compatible avec la plus ancienne version de Python 2 que vous souhaitez, vous devez vous assurer que votre suite de test a une couverture suffisante. Une bonne règle empirique consiste à avoir suffisamment confiance en la suite de test pour qu'une erreur apparaissant après la réécriture du code par les outils automatiques résulte de bogues de ces derniers et non de votre code. Si vous souhaitez une valeur cible, essayez de dépasser les 80 % de couverture (et ne vous sentez pas coupable si vous trouvez difficile de faire mieux que 90 % de couverture). Si vous ne disposez pas encore d'un outil pour mesurer la couverture de code, coverage.py est recommandé.

### Apprendre les différences entre Python 2 et 3

Une fois que votre code est bien testé, vous êtes prêt à démarrer votre portage vers Python 3 ! Mais afin de comprendre comment votre code va changer et à quoi s'intéresser spécifiquement pendant que vous codez, vous aurez sûrement envie de découvrir quels sont les changements introduits par Python 3 par rapport à Python 2. Pour atteindre cet objectif, les deux meilleurs moyens sont de lire le document whatsnew-index de chaque version de Python 3 et le livre Porting to Python 3 (gratuit en ligne, en anglais). Il y a également une « anti-sèche » (cheat sheet, ressource en anglais) très pratique du projet Python-Future.

### Mettre à jour votre code

Une fois que vous pensez en savoir suffisamment sur les différences entre Python 3 et Python 2, il est temps de mettre à jour votre code ! Vous avez le choix entre deux outils pour porter votre code automatiquement : Futurize et Modernize. Le choix de l'outil dépend de la dose de Python 3 que vous souhaitez introduire dans votre code. Futurize s'efforce d'introduire les idiomes et pratiques de Python 3 dans Python 2, par exemple en réintroduisant le type `bytes` de Python 3 de telle sorte que la sémantique soit identique entre les deux versions majeures de Python. En revanche, Modernize est plus conservateur et vise un sous-ensemble d'instructions Python 2/3, en s'appuyant directement sur six pour la compatibilité. Python 3 étant le futur de Python, il pourrait être préférable d'utiliser Futurize afin de commencer à s'ajuster aux nouvelles pratiques introduites par Python 3 avec lesquelles vous n'êtes pas encore habitué.

Indépendamment de l'outil sur lequel se porte votre choix, celui-ci mettra à jour votre code afin qu'il puisse être exécuté par Python 3 tout en maintenant sa compatibilité avec la version de Python 2 dont vous êtes parti. En fonction du niveau de prudence que vous visez, vous pouvez exécuter l'outil sur votre suite de test d'abord puis inspecter visuellement la différence afin de vous assurer que la transformation est exacte. Après avoir transformé votre suite de test et vérifié que tous les tests s'exécutent comme attendu, vous pouvez transformer le code de votre application avec l'assurance que chaque test qui échoue correspond à un échec de traduction.

Malheureusement les outils ne peuvent pas automatiser tous les changements requis pour permettre à votre code de s'exécuter sous Python 3 et il y a donc quelques points sur lesquels vous devrez travailler manuellement afin d'atteindre la compatibilité totale Python 3 (les étapes nécessaires peuvent varier en fonction de l'outil utilisé). Lisez la documentation de l'outil que vous avez choisi afin d'identifier ce qu'il corrige par défaut et ce qui peut être appliqué de façon optionnelle afin de savoir ce qui sera (ou non) corrigé pour vous ou ce que vous devrez modifier vous-même (par exemple, le remplacement `io.open()` plutôt que la fonction native `open()` est inactif par défaut dans Modernize). Heureusement, il n'y a que quelques points à surveiller qui peuvent réellement être considérés comme des problèmes difficiles à déboguer si vous n'y prêtez pas attention.

#### Division

Dans Python 3, `5 / 2 == 2.5` et non `2`; toutes les divisions entre des valeurs `int` renvoient un `float`. Ce changement était en réalité planifié depuis Python 2.2, publié en 2002. Depuis cette date, les utilisateurs ont été encouragés à ajouter `from __future__ import division` à tous les fichiers utilisant les opérateurs `/` et `//` ou à exécuter l'interpréteur avec l'option `-Q`. Si vous n'avez pas suivi cette recommandation, vous devrez manuellement modifier votre code et effectuer deux changements :

1. Ajouter `from __future__ import division` à vos fichiers

2. Remplacer tous les opérateurs de division par `//` pour la division entière, le cas échant, ou utiliser `/` et vous attendre à un résultat flottant

La raison pour laquelle `/` n'est pas simplement remplacé par `//` automatiquement est que si un objet définit une méthode `__truediv__` mais pas de méthode `__floordiv__`, alors votre code pourrait produire une erreur (par exemple, une classe définie par l'utilisateur qui utilise `/` pour définir une opération quelconque mais pour laquelle `//` n'a pas du tout la même signification, voire n'est pas utilisé du tout).

#### Texte et données binaires

Dans Python 2, il était possible d'utiliser le type `str` pour du texte et pour des données binaires. Malheureusement cet amalgame entre deux concepts différents peut conduire à du code fragile pouvant parfois fonctionner pour les deux types de données et parfois non. Cela a également conduit à des API confuses si les auteurs ne déclaraient pas explicitement que quelque chose qui acceptait `str` était compatible avec du texte ou des données binaires et pas un seul des deux types. Cela a compliqué la situation pour les personnes devant gérer plusieurs langages avec des API qui ne se préoccupaient pas de la gestion de `unicode` lorsqu'elles affirmaient être compatibles avec des données au format texte.

Afin de rendre la distinction entre texte et données binaires claire et prononcée, Python 3 a suivi la voie pavée par la plupart des langages créés à l'ère d'Internet et a séparé les types texte et données binaires de telle sorte qu'il ne soit plus possible de les confondre (Python est antérieur à la démocratisation de l'accès à Internet). Cette séparation ne pose pas de problème pour du code ne gérant soit que du texte, soit que des données binaires. Cependant un code source devant gérer les deux doit désormais se préoccuper du type des données manipulées, ce qui explique que ce processus ne peut pas être entièrement automatisé.

Pour commencer, vous devrez choisir quelles API travaillent sur du texte et lesquelles travaillent avec des données binaires (il est fortement recommandé de ne pas concevoir d'API qui gèrent les deux types compte-tenu de la difficulté supplémentaire que cela induit). Dans Python 2, cela signifie s'assurer que les API recevant du texte en entrée peuvent gérer `unicode` et celles qui reçoivent des données binaires fonctionnent avec le type `bytes` de Python 3 (qui est un sous-ensemble de `str` dans Python 2 et opère comme un alias du type `bytes` de Python 2). En général, le principal problème consiste à inventorier quelles méthodes existent et opèrent sur quel type dans Python & 3 simultanément (pour le texte, il s'agit de `unicode` dans Python 2 et `str` dans Python 3, pour le binaire il s'agit de `str`/`bytes` dans Python 2 et `bytes` dans Python 3). Le tableau ci-dessous liste les méthodes spécifiques à chaque type de données dans Python 2 et 3 (par exemple, la méthode `decode()` peut être utilisée sur des données binaires équivalentes en Python 2 et 3, mais ne peut pas être utilisée de la même façon sur le type texte en Python 2 et 3 car le type `str` de Python 3 ne possède pas de telle méthode). Notez que depuis Python 3.5, la méthode `__mod__` a été ajoutée au type bytes.

Format texte | Format binaire
| decode
encode |
format |
isdecimal |
isnumeric |

Vous pouvez rendre le problème plus simple à gérer en réalisant les opérations d'encodage et de décodage entre données binaires et texte aux extrémités de votre code. Cela signifie que lorsque vous recevez du texte dans un format binaire, vous devez immédiatement le décoder. À l'inverse si votre code doit transmettre du texte sous forme binaire, encodez-le le plus tard possible. Cela vous permet de ne manipuler que du texte à l'intérieur de votre code et permet de ne pas se préoccuper du type des données sur lesquelles vous travaillez.

Le point suivant est de s'assurer que vous savez quelles chaînes de caractères littérales de votre code correspondent à du texte ou à du binaire. Vous devez préfixer par `b` tous les littéraux qui représentent des données binaires et par `u` les littéraux qui représentent du texte (il existe une importation du module `__future__` permettant de forcer l'encodage de toutes les chaînes de caractères littérales non spécifiées en Unicode, mais cette pratique s'est avérée moins efficace que l'ajout explicite des préfixe `b` et `u`).

Une conséquence de cette dichotomie est que vous devez être prudents lors de l'ouverture d'un fichier. À moins que vous travailliez sous Windows, il y a des chances pour que vous ne vous soyez jamais préoccupé de spécifier le mode `b` lorsque vous ouvrez des fichiers binaires (par exemple `rb` pour lire un fichier binaire). Sous Python 3, les fichiers binaire et texte sont distincts et mutuellement incompatibles ; se référer au module `io` pour plus de détails. Ainsi vous devez décider lorsque vous ouvrez un fichier si vous y accéderez en mode binaire (ce qui permet de lire et écrire des données binaires) ou en mode texte (ce qui permet de lire et écrire du texte). Vous devez également utiliser `io.open()` pour ouvrir des fichiers plutôt que la fonction native `open()` étant donné que le module `io` est cohérent de Python 2 à 3, ce qui n'est pas vrai pour la fonction `open()` (en Python 3, il s'agit en réalité de `io.open()`). Ne cherchez pas à appliquer l'ancienne pratique consistant à utiliser `codecs.open()` qui n'est nécessaire que pour préserver une compatibilité avec Python 2.5.

Les constructeurs des types `str` et `bytes` possèdent une sémantique différente pour les mêmes arguments sous Python 2 et 3. Passer un entier à `bytes` sous Python 2 produit une représentation de cet entier en chaîne de caractères : `bytes(3) == '3'`. Mais sous Python 3, fournir un argument entier à `bytes` produit un objet bytes de la longueur de l'entier spécifié, rempli par des octets nuls : `bytes(3) == b'\x00\x00\x00'`. La même prudence est nécessaire lorsque vous passez un objet bytes à `str`. En Python 2, vous récupérez simplement l'objet bytes initial : `str(b'3') == b'3'`. Mais en Python 3, vous récupérez la représentation en chaîne de caractères de l'objet bytes : `str(b'3') == "b'3'"`.

Enfin, l'indiçage des données binaires exige une manipulation prudente (bien que le découpage, ou slicing en anglais, ne nécessite pas d'attention particulière). En Python 2, `b'123'[1] == b'2'` tandis qu'en Python 3 `b'123'[1] == 50`. Puisque les données binaires ne sont simplement qu'une collection de nombres en binaire, Python 3 renvoie la valeur entière de l'octet indicé. Mais en Python 2, étant donné que `bytes == str`, l'indiçage renvoie une tranche de longueur 1 de bytes. Le projet six dispose d'une fonction appelée `six.indexbytes()` qui renvoie un entier comme en Python 3 : `six.indexbytes(b'123', 1)`.

Pour résumer :

1. Décidez lesquelles de vos API travaillent sur du texte et lesquelles travaillent sur des données binaires

2. Assurez vous que votre code travaillant sur du texte fonctionne aussi avec le type `unicode` et que le code travaillant sur du binaire fonctionne avec le type `bytes` en Python 2 (voir le tableau ci-dessus pour la liste des méthodes utilisables par chaque type)

3. Préfixez tous vos littéraux binaires par `b` et toutes vos chaînes de caractères littérales par `u`

4. Décodez les données binaires en texte dès que possible, encodez votre texte au format binaire le plus tard possible

5. Ouvrez les fichiers avec la fonction `io.open()` et assurez-vous de spécifier le mode `b` le cas échéant

6. Utilisez avec prudence l'indiçage sur des données binaires

#### Utilisez la détection de fonctionnalités plutôt que la détection de version

Vous rencontrerez inévitablement du code devant décider quoi faire en fonction de la version de Python qui s'exécute. La meilleure façon de gérer ce cas est de détecter si les fonctionnalités dont vous avez besoin sont gérées par la version de Python sous laquelle le code s'exécute. Si pour certaines raisons cela ne fonctionne pas, alors vous devez tester si votre version est Python 2 et non Python 3. Afin de clarifier cette pratique, voici un exemple.

Supposons que vous avez besoin d'accéder à une fonctionnalité de `importlib` qui est disponible dans la bibliothèque standard de Python depuis la version 3.3, dans celle de Python 2 via le module importlib2 sur PyPI. Vous pourriez être tenté d'écrire un code qui accède, par exemple, au module `importlib.abc` avec l'approche suivante :

    import sys

    if sys.version_info[0] == 3:
        from importlib import abc
    else:
        from importlib2 import abc

Le problème est le suivant : que se passe-t-il lorsque Python 4 est publié ? Il serait préférable de traiter le cas Python 2 comme l'exception plutôt que Python 3 et de supposer que les versions futures de Python 2 seront plus compatibles avec Python 3 qu'avec Python 2 :

    import sys

    if sys.version_info[0] > 2:
        from importlib import abc
    else:
        from importlib2 import abc

Néanmoins la meilleure solution est de ne pas chercher à déterminer la version de Python mais plutôt à détecter les fonctionnalités disponibles. Cela évite les problèmes potentiels liés aux erreurs de détection de version et facilite la compatibilité future :

    try:
        from importlib import abc
    except ImportError:
        from importlib2 import abc

### Prévenir les régressions de compatibilité

Une fois votre code traduit pour être compatible avec Python 3, vous devez vous assurer que votre code n'a pas régressé ou qu'il ne fonctionne pas sous Python 3. Ceci est particulièrement important si une de vos dépendances vous empêche de réellement exécuter le code sous Python 3 pour le moment.

Afin de vous aider à maintenir la compatibilité, nous préconisons que tous les nouveaux modules que vous créez aient au moins le bloc de code suivant en en-tête :

    from __future__ import absolute_import
    from __future__ import division
    from __future__ import print_function

Vous pouvez également lancer Python 2 avec le paramètre `-3` afin d'être alerté en cas de divers problèmes de compatibilité que votre code déclenche durant son exécution. Si vous transformez les avertissements en erreur avec `-Werror`, vous pouvez être certain que ne passez pas accidentellement à côté d'un avertissement.

Vous pouvez également utiliser le projet Pylint et son option `--py3k` afin de modifier votre code pour recevoir des avertissements lorsque celui-ci dévie de la compatibilité Python 3. Cela vous évite par ailleurs d'appliquer Modernize ou Futurize sur votre code régulièrement pour détecter des régressions liées à la compatibilité. Cependant cela nécessite de votre part le support de Python 2.7 et Python 3.4 ou ultérieur étant donné qu'il s'agit de la version minimale gérée par Pylint.

### Vérifier quelles dépendances empêchent la migration

Après avoir rendu votre code compatible avec Python 3, vous devez commencer à vous intéresser au portage de vos dépendances. Le projet caniusepython3 a été créé afin de vous aider à déterminer quels projets sont bloquants dans votre support de Python 3, directement ou indirectement. Il existe un outil en ligne de commande ainsi qu'une interface web : https://caniusepython3.com.

Le projet fournit également du code intégrable dans votre suite de test qui déclenchera un échec de test lorsque plus aucune de vos dépendances n'est bloquante pour l'utilisation de Python 3. Cela vous permet de ne pas avoir à vérifier manuellement vos dépendances et d'être notifié rapidement quand vous pouvez exécuter votre application avec Python 3.

### Mettre à jour votre fichier `setup.py` pour spécifier la compatibilité avec Python 3

Une fois que votre code fonctionne sous Python 3, vous devez mettre à jour vos classeurs dans votre `setup.py` pour inclure `Programming Language :: Python :: 3` et non seulement le support de Python 2. Cela signifiera à quiconque utilise votre code que vous gérez Python 2 et 3. Dans l'idéal vous devrez aussi ajouter une mention pour chaque version majeure/mineure de Python que vous supportez désormais.

### Utiliser l'intégration continue pour maintenir la compatibilité

Une fois que vous êtes en mesure d'exécuter votre code sous Python 3, vous devrez vous assurer que celui-ci fonctionne toujours pour Python 2 & 3. tox est vraisemblablement le meilleur outil pour exécuter vos tests avec plusieurs interpréteurs Python. Vous pouvez alors intégrer tox à votre système d'intégration continue afin de ne jamais accidentellement casser votre gestion de Python 2 ou 3.

Vous pouvez également utiliser l'option `-bb` de l'interpréteur Python 3 afin de déclencher une exception lorsque vous comparez des bytes à des chaînes de caractères ou à un entier (cette deuxième possibilité est disponible à partir de Python 3.5). Par défaut, des comparaisons entre types différents renvoient simplement `False` mais si vous avez fait une erreur dans votre séparation de la gestion texte/données binaires ou votre indiçage des bytes, vous ne trouverez pas facilement le bogue. Ce drapeau lève une exception lorsque ce genre de comparaison apparaît, facilitant ainsi son identification et sa localisation.

Et c'est à peu près tout ! Une fois ceci fait, votre code source est compatible avec Python 2 et 3 simultanément. Votre suite de test est également en place de telle sorte que vous ne cassiez pas la compatibilité Python 2 ou 3 indépendamment de la version que vous utilisez pendant le développement.

### Envisager l'utilisation d'un vérificateur de type statique optionnel

Une autre façon de faciliter le portage de votre code est d'utiliser un vérificateur de type statique comme mypy ou pytype. Ces outils peuvent être utilisés pour analyser votre code comme s'il était exécuté sous Python 2, puis une seconde fois comme s'il était exécuté sous Python 3. L'utilisation double d'un vérificateur de type statique de cette façon permet de détecter si, par exemple, vous faites une utilisation inappropriée des types de données binaires dans une version de Python par rapport à l'autre. Si vous ajoutez les indices optionnels de typage à votre code, vous pouvez alors explicitement déclarer que vos API attendent des données binaires ou du texte, ce qui facilite alors la vérification du comportement de votre code dans les deux versions de Python.