Neues in Python 3.4

Seite 4: Ausblick und Fazit

Inhaltsverzeichnis

Die Adaption von Python 3 – oder vielmehr deren Mangel – bleibt weiter ein Thema in der Python-Community. Zwar sind mittlerweile die meisten der großen Bibliotheken und Toolkits portiert – zu nennen sind vor allem Django und scipy – und auch die großen Linux-Distributionen Ubuntu und Fedora planen für die kommenden Versionen den Umstieg. Viele Unternehmen, die Python einsetzen, berichten jedoch, dass ein Wechsel auf Version 3 nicht vorgesehen sei.

Python-Erfinder Guido van Rossum, der bei Dropbox arbeitet, hat selbst bestätigt, dass man auch dort bis auf Weiteres auf Python 2 setze. Fragen nach einer Version 2.8 hat man in der Python-Entwicklercommunity bisher stets verneint – weder glaube man, dass sich dadurch die Portierung auf Python 3 erleichtern ließe, noch habe jemand Lust, an der alten Codebasis weiterzuentwickeln. Dennoch ist zu erwarten, dass in Zukunft Änderungen wie PEP 461 (Formatierung mit dem %-Operator für byte-Objekte), die die Portierung zwischen den Versionen erleichtern, aufgenommen werden. Außerdem verlängerte man zuletzt die Unterstützung für Python 2.7 um fünf Jahre bis 2020.

Bis zu einer neuen Version dauert es gewöhnlich 18 Monate - man darf also frühestens im September 2015 mit Python 3.5 rechnen. Relativ sicher scheint, dass ein neuer Operator für Matrix-Multiplikationen in die Sprache Einzug halten wird. PEP 465 schlägt dafür das Zeichen @ vor. Guido van Rossum hat angedeutet, dass er den Vorschlag akzeptieren werde, sobald die Community rund um numerische Bibliotheken sich auf Details wie Rechts- oder Linksassoziativität geeinigt habe.

Diese Änderung trägt der stark gestiegenen Bedeutung von Python im wissenschaftlichen Umfeld Rechnung. Weitere Vorschläge, die eine realistische Chance darauf haben, in Python 3.5 umgesetzt zu werden, sind eine generalisierte Unpacking-Syntax für Containertypen, welche die bisherige Syntax von einigen Einschränkungen befreit (PEP 448), und ein spezielles Dictionary, das es erlaubt, den Wert der Schlüssel mit einer Funktion zu transformieren (PEP 455).

In den letzten Jahren hat außerdem die alternative Implementierung PyPy von sich reden gemacht. Sie implementiert Python nicht in C, sondern in Python (zumindest einem Subset davon). Das klingt eigenartig, aber mit seinem Just-In-Time Compiler (JIT) ist PyPy oft deutlich schneller als CPython, wie Benchmarks zeigen. Es gibt aber noch Baustellen, wie das Modul pypy3, das Python-3-Kompatibilität herstellen soll, und numpypy, eine Neu-Implementierung von numpy, die den JIT besser nutzen soll.

Ein weiteres Projekt aus dem PyPy-Umfeld ist CFFI, eine Schnittstelle zwischen Python und C, die sowohl mit CPython als auch mit PyPy funktioniert und dabei robuster und schneller ist als ctypes. Es ist nicht unwahrscheinlich, das in näherer Zukunft eine Aufnahme von CFFI in die Standardbibliothek vorgeschlagen wird.

Noch ein reines Forschungsprojekt ist pypy-stm, dass mit Software Transactional Memory eine Alternative zu locking in Multithread-Umgebungen anbietet. Einer der Vorzüge dieses Modells ist es, den berüchtigten Global Interpreter Lock (GIL) von Python zu beseitigen und somit ein Python-Programm nahezu linear mit den vorhandenen Prozessoren skalieren lassen zu können. Bis dahin ist es allerdings noch ein weiter Weg.

Dass hinter Python kein großes Unternehmen wie Microsoft oder Oracle steht, hat sich für die Sprache nicht als Nachteil erwiesen – ganz im Gegenteil: Der offene Entwicklungsprozess stellt sicher, dass die Python-Entwickler in engem Kontakt zu den Nutzern stehen. Der Spagat zwischen konservativer Stabilität und Anpassung an neue Bedürfnisse ist mit Python 3.4 gelungen. Das neue Modul asyncio etabliert Python als ernsthaften Konkurrenten zu Node.js, pip erleichtert den Umgang mit Fremdbibliotheken, und eine Vielzahl von Änderungen verbessert die Sicherheit von Python-Software. Ob die neuen Features Lockmittel genug sind, um verbliebene Python-2-Nutzer zur Migration zu bewegen, wird sich zeigen. Für den Autor ist asyncio der spannendste Neuzugang und Grund genug, Python 3.4 eine Chance zu geben.

Christian Schramm
begeistert sich für eleganten und lesbaren Programmcode. Er ist selbständiger Softwareentwickler und berät Unternehmen zum Einsatz von Open-Source-Software in der Entwicklung.
(jul)