Un peu plus de trois ans après la dernière version principale, IPython 8 est maintenant disponible. Lors du développement de l’interpréteur interactif en ligne de commande pour Python, l’accent a été mis en premier lieu sur des travaux de nettoyage : la version a une base de code plus légère et supprime de nombreuses fonctions marquées comme obsolètes (deprecated). Parmi les nouveautés, il faut surtout mentionner le traçage étendu des erreurs et les suggestions automatiques de lignes de code.

Quelques modifications des dépendances y sont également liées. En ce qui concerne le langage de programmation, la console fonctionnant selon le principe REPL (Read Eval Print Loop) requiert désormais Python 3.8. Le paquet traitlets doit être disponible au moins dans la version 5, et IPython nécessite depuis peu le paquet stack_data.

Pour le testing, il y a également des adaptations : pytest remplace nose, et les points d’entrée iptest respectivement iptest3 ont été supprimées. Pour l’interaction avec NumPy, la version 1.19 au minimum est désormais requise sur la base du NumPy Enhancement Proposal (NEP) 29.

Propositions constructives

En plus de l’autocomplétion, IPython propose depuis peu ce que l’on appelle des autosuggestions : la console propose des commandes en fonction des commandes utilisées jusqu’à présent. Les suggestions apparaissent en gris à côté du curseur et peuvent être modifiées par Ctrl-f, Ctrl-e ou la Droite-pour accepter le message. Une pression sur Alt-f n’accepte que le premier mot.

Actuellement, IPython n’affiche les suggestions que dans les modes Vi (ViInsertMode) et Emacs (EmacsInsertMode), et les raccourcis clavier ne fonctionnent sans adaptation que dans ce dernier. Indépendamment des propositions, l’appui sur la touche Onglet-la fonction d’autocomplétion est activée et les propositions sont listées de manière habituelle.

Plus de visibilité sur les messages d’erreur

Le suivi des messages d’erreur affiche désormais le nœud concerné dans l’arbre de syntaxe abstraite (AST) de la source d’erreur au lieu d’un hash pour les cellules de code et met en évidence les éléments sur le terminal ou dans les ordinateurs portables.

De plus, pour les erreurs dans les fichiers, le traçage affiche le nom du fichier suivi de deux deux points et du numéro de ligne qui suit avec l’erreur :

File ~/fehler.py:7, in <module>

Important travail de nettoyage

Un article de blog spécifique décrit les travaux de nettoyage et de désencombrement de la base de code. Il en est ressorti quelques bonnes pratiques pour le travail futur. Entre autres, le logiciel compare désormais les numéros de version des importations au lieu d’intercepter les importations obsolètes ou manquantes via des blocs try-except, comme dans l’héritage supprimé suivant dans le code IPython :

try:
    from numpy.testing import KnownFailure, knownfailureif
except ImportError:
    from ._decorators import knownfailureif
    try:
        from ._numpy_testing_noseclasses import KnownFailure
    except ImportError:
        pass

Planifier ou intercepter

Le débat entre LBYL (Look Before You Leap) et EAFP (Easier to Ask Forgiveness than Permissions) n’est pas nouveau. Le premier décrit la vérification des conditions préalables telles que les importations nécessaires, la présence d’une variable ou d’un index correct avant une ligne de code, tandis que le second intercepte les erreurs par des exceptions. Dans de nombreux cas, EAFP est considéré comme « pythonic », c’est-à-dire plus adapté au langage de programmation.

Les partisans citent de meilleures performances et une meilleure lisibilité comme avantages. L’article de blog sur le nettoyage d’IPython 8 conclut cependant qu’EAFP présente plus d’inconvénients que d’avantages pour les importations. Selon eux, les différences de performance sont négligeables et la lisibilité gagne à être précédée de requêtes, car des blocs try-except imbriqués sont souvent nécessaires, comme le montre l’exemple ci-dessus.

Parmi les autres bonnes pratiques, l’article cite des avertissements étendus pour les fonctions obsolètes sur DeprecationWarning et l’utilisation de stacklevel sur.

IPython est né en tant qu’interpréteur en ligne de commande pour le langage de programmation Python, qui mise sur un mode de travail interactif comme REPL. Le projet est issu du milieu universitaire : Fernando Pérez l’a développé en 2001 parce qu’il manquait à Python un bloc-notes comme dans Mathematica.

IPython sépare le frontend avec la couche de représentation du backend. Les deux côtés peuvent ainsi être échangés. Pour la messagerie, la bibliothèque ZeroMQ (ØMQ) est utilisée. Des détails sur le mode de fonctionnement se trouvent dans la documentation sur le mode de fonctionnement de l’outil.

À l’origine, IPython était lié au Jupyter Notebook, qui s’est détaché en 2017 avec la version 5.0 en tant que projet indépendant.

Entre la version 7, publiée en septembre 2018, et IPython 8, il s’est écoulé un long laps de temps par rapport aux versions précédentes, probablement dû en grande partie à un important travail de nettoyage.

De plus amples détails peuvent être trouvés sur le blog de Jupyter. Une description détaillée des nouveautés se trouve dans la documentation d’IPython. À l’avenir, les versions mineures devraient si possible être publiées chaque mois, le dernier vendredi du mois. Pour IPython 7.x, des corrections de bugs critiques sont prévues dans un premier temps.