Kommandozeileninterpreter IPython 8 macht konstruktive Vorschläge

Autosuggestions beruhen auf bisherigen Eingaben und ergänzen die Autovervollständigung. Das neue Release schneidet zudem zahlreiche alte Zöpfe ab.

In Pocket speichern vorlesen Druckansicht
Schlange, Python, Paradies

(Bild: Michael Schwarzenberger, gemeinfrei (Creative Commons CC0))

Lesezeit: 4 Min.
Von
  • Rainald Menge-Sonnentag
Inhaltsverzeichnis

Gut drei Jahre nach der letzten Hauptversion ist nun IPython 8 erschienen. Bei der Entwicklung des interaktiven Kommandozeileninterpreters für Python standen in erster Linie Aufräumarbeiten im Vordergrund: Das Release hat eine schlankere Codebase und entfernt zahlreiche als überholt (deprecated) markierte Funktionen. Bei den Neuerungen sind vor allem das erweiterte Traceback für Fehler und die automatischen Vorschläge für Codezeilen zu nennen.

Damit verbunden sind auch einige Änderungen bei den Dependencies. Bei der Programmiersprache setzt die nach dem REPL-Prinzip (Read Eval Print Loop) arbeitende Konsole nun Python 3.8 voraus. Das Paket traitlets muss mindestens in Version 5 vorliegen, und IPython benötigt neuerdings das Paket stack_data.

Für das Testing gibt es ebenfalls Anpassungen: pytest ersetzt nose, und die Entrypoints iptest beziehungsweise iptest3 entfallen. Für das Zusammenspiel mit NumPy ist nun auf Grundlage des NumPy Enhancement Proposal (NEP) 29 mindestens Version 1.19 erforderlich.

Neben der Autovervollständigung bietet IPython neuerdings sogenannte Autosuggestions: Die Konsole schlägt Kommandos aufgrund der bisher verwendeten Befehle vor. Die Vorschläge erscheinen grau neben dem Cursor und lassen sich durch Strg-f, Strg-e oder die Rechts-Taste annehmen. Ein Druck auf Alt-f nimmt nur das erste Wort an.

Die Vorschläge beruhen auf der Historie der Eingaben.

(Bild: IPython)

Derzeit zeigt IPython die Vorschläge nur in den Modi Vi (ViInsertMode) und Emacs (EmacsInsertMode) an, und die Tastenkürzel funktionieren ohne Anpassungen nur in Letzterem. Unabhängig von den Vorschlägen ruft der Druck auf die Tab-Taste die Autovervollständigungsfunktion auf und listet die Vorschläge in gewohnter Weise auf.

Die Tracebacks für Fehlermeldungen zeigen nun statt einem Hash für Codezellen den betroffenen Knoten im Abstract Syntax Tree (AST) der Fehlerquelle an und heben die Elemente auf dem Terminal beziehungsweise in Notebooks hervor.

Die Tracebacks für Fehler sind deutlich übersichtlicher als bisher.

(Bild: IPython)

Außerdem zeigt das Traceback für Fehler in Dateien den Dateinamen gefolgt von zwei Doppelpunkten und der anschließenden Zeilennummer mit dem Fehler an:

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

Ein eigener Blogbeitrag beschreibt die Arbeiten zum Aufräumen und Entschlacken der Codebase. Daraus haben sich einige Best Practices für die künftige Arbeit ergeben. Unter anderem vergleicht die Software neuerdings Versionsnummern von Importen, statt wie bisher veraltete oder fehlende Importe über Try-Except-Blöcke abzufangen, wie in folgender entfernten Altlast im IPython-Code:

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

Die Debatte um LBYL (Look Before You Leap) versus EAFP (Easier to Ask Forgiveness than Permissions) ist nicht neu. Ersteres beschreibt das Prüfen von Voraussetzungen wie benötigten Importen, Vorhandensein einer Variable oder einem korrekten Index vor einer Codezeile, während Letzteres Fehler durch Exceptions abfängt. Vielfach wird EAFP als "Pythonic" angesehen, also passender für die Programmiersprache.

Die Befürworter führen bessere Performance und Lesbarkeit als Vorteile auf. Der Blogbeitrag zu den Aufräumarbeiten in IPython 8 kommt aber zu dem Schluss, dass EAFP für Importe mehr Nach- als Vorteile hat. Die Unterschiede bei der Performance seien zu vernachlässigen, und die Lesbarkeit gewinnt durch die vorherigen Abfragen, da oft verschachtelte Try-Except-Blöcke erforderlich sind, wie obiges Beispiel zeigt.

Als weitere Best Practices führt der Beitrag umfangreiche Warnungen bei veralteten Funktionen über DeprecationWarning und den Einsatz von stacklevel auf.

Die Wurzeln der Jupyter Notebooks

Die grundlegende Architektur mit Terminal und IPython-Kernel.

IPython ist als Kommandozeileninterpreter für die Programmiersprache Python entstanden, der auf eine interaktive Arbeitsweise als REPL setzt. Das Projekt stammt aus dem universitären Umfeld: Fernando Pérez hat es 2001 entwickelt, weil er in Python ein Notebook wie in Mathematica vermisst hat.

IPython trennt das Frontend mit der Darstellungsebene vom Backend. Damit lassen sich beide Seiten austauschen. Für das Messaging kommt die ZeroMQ-Library (ØMQ) zum Einsatz. Details zur Arbeitsweise finden sich in der Dokumentation zur Arbeitsweise des Werkzeugs.

Ursprünglich war IPython mit dem Jupyter Notebook verbunden, das sich 2017 mit der Version 5.0 als eigenständiges Projekt gelöst hat.

Zwischen der im September 2018 veröffentlichten Version 7 und IPython 8 ist im Vergleich zu den Vorversionen ein langer Zeitraum vergangen, der wohl vor allem den umfangreichen Aufräumarbeiten geschuldet ist.

Weitere Details lassen sich dem Jupyter-Blog entnehmen. Eine ausführliche Beschreibung der Neuerungen findet sich in der IPython-Dokumentation. Künftig sollen möglichst monatlich Minor Releases jeweils am letzten Freitag des Monats erscheinen. Für IPython 7.x soll es zunächst weiterhin kritische Bugfixes geben.

(rme)