Python für .Net erhebt sich von den Toten

Die Entwicklung auf IronPython, einer Python-Implementierung, die auf der Common Language Runtime (CLR) des .Net-Frameworks ausgeführt wird, ist dank des Projekts, das kürzlich den Besitzer eines neuen Entwicklungsleiters gewechselt hat, ein Kinderspiel.

Jeff Hardy, ehemaliger führender IronPython-Entwickler, bestätigte den Übergang auf der Mailingliste der Ironpython-Benutzer Anfang dieses Monats. "Aus vielen Gründen habe ich momentan einfach nicht die Zeit, IronPython die Aufmerksamkeit zu schenken, die es verdient", schrieb Hardy. "Deshalb übergebe ich die Kontrolle über das Projekt an Alex Earl und Benedikt Eggers."

Ein Python für .Net und umgekehrt

IronPython, geschrieben in C #, ist nicht nur zum Ausführen von Standard-Python-Programmen gedacht. Es kann Python-Programmierern eine Brücke zu vorhandenen .NET-Anwendungen und -Objekten bieten. Das Beste ist, dass diese Objekte mit derselben Syntax und denselben Redewendungen wie native Python-Objekte importiert und verarbeitet werden können.

Die Entwicklung von IronPython hat sich in den letzten Jahren zweifellos verlangsamt. Die letzte Hauptversion war Ende 2014 für Python 2.7.5. Python 3 wurde von IronPython nicht unterstützt - ein großer Nachteil, da Python 2 ab 2020 nicht mehr unterstützt wird und Python 3 der etablierte Nachfolger ist.

In einem Meeting auf der Entwickler-Chat-Site Gitter haben Earl, Eggers und andere die dringendsten Probleme des Projekts im weiteren Verlauf herausgearbeitet: Was tun bei ausstehenden IronPython-Problemen in CodePlex? Welche Art von Release-Zeitplan muss implementiert werden? und welche Art von Roadmap für IronPython 3 zu erstellen ist.

Ein weiteres Problem, das in den Diskussionen auftauchte, war die Implementierung der Unterstützung für Python-Bibliotheken, die C-Erweiterungen verwenden. Wenn IronPython ein möglichst breites Publikum haben soll, ist dies keine Option. Viele wichtige Python-Bibliotheken, wie Numpy, verwenden C-Erweiterungen, um die Geschwindigkeit zu erhöhen, und sie sollten idealerweise so wie sie sind in IronPython funktionieren, ohne neu kompiliert werden zu müssen.

Die gute Nachricht ist, dass in diesem Bereich bereits einige Arbeiten durchgeführt wurden, nämlich Ironclad, ein Projekt, mit dem kompilierte CPython-Erweiterungen in IronPython unverändert funktionieren sollen. Die schlechte Nachricht ist, dass das Projekt seit langem nicht mehr viel Arbeit gesehen hat und stark überarbeitet werden muss, um für modernes Python nützlich zu sein.

Von Rubinen und Gils

Ein weiteres Problem war, wie man mit einem ähnlichen Projekt umgeht, das vom selben Team bearbeitet wird: IronRuby, eine .NET-Implementierung von Ruby, wie der Name schon sagt. Die beiden Sprachen wurden gemeinsam entwickelt, da sie aus denselben Bemühungen innerhalb von Microsoft rund um die Dynamic Language Runtime hervorgegangen sind und sich in unmittelbarer Nähe befanden, nachdem Microsoft sie 2010 in Community-gesteuerte Bemühungen ausgegliedert hatte.

Es ist geplant, IronRuby zu einem eigenen Projekt zu machen, um das eigene Entwicklerpublikum anzulocken. IronPython 2 wird auch weiterhin als eigenständiges Projekt entwickelt.

Zukünftige IronPython-Entwicklungen können sich als fruchtbar erweisen, indem sie den langjährigen Traum einer schnellen, multicore-freundlichen Python-Laufzeit erfüllen. IronPython verfügt nicht über eine globale Interpreter-Sperre (GIL), eine Funktion vieler Python-Implementierungen, die als Hindernis für eine hohe Leistung angesehen wird.

Die Tatsache, dass IronPython keine GIL hat, macht es jedoch nicht automatisch schneller. Einige IronPython-Benchmarks sind besser als CPython, andere sind deutlich schlechter. Im Moment sollte es Mission genug sein, IronPython einfach mit den aktuellen Python-Zweigen 2 und 3 auf den neuesten Stand zu bringen.