Der diesjährige Language Summit (Gipfeltreffen zur Sprache) fand am 10. März --
am Tag vor der PyCon -- in Atlanta statt. Zugegen waren Entwickler der VMs
CPython, PyPy, Jython, IronPython und Parrot,
Packaging-Entwickler von Fedora, Ubuntu und Debian, sowie Mitglieder
des Twisted Projekts und viele andere.
Entwicklungs-Blog
Einer der ersten Tagesordnungspunkte war die Diskussion eben dieses Blogs,
angestoßen vom PSF Communications Officer Doug Hellmann. Wegen des hohen
Verkehrs und der oft heftigen Art auf der python-dev Mailingliste, hofft dieses
Blog für User einen einfachere Möglichkeit zu bieten, sich über die Entwicklung
zu informieren. Wir planen PEPs, jede größere Entscheidung, neue Features und
kritische Bug Fixes abzudecken und informell darüber zu berichten, was im
Entwicklungsprozess geschieht.
Jeder Python-Implementierung steht es frei in dem Blog zu
schreiben. Beispielsweise sind die PyPy-Entwickler eingeladen ihre Neuigkeiten
auch hier zu veröffentlichen, auch wenn sie schon ihr eigenes aktives Blog haben. Eine verwandte Nebendiskussion führte
dazu, dass alternative Implementierungen ebenfalls auf der python.org
Downloadseite erwähnt werden. Ihre Releases
werden nun auch als Neuigkeiten auf der python.org Startseite aufgeführt.
Kompatibilitätswarnungen
Mit 3.2 haben wurde ResourceWarning eingeführt, um es Nutzern zu erlauben
Code-Bereiche zu finden, die sich auf CPythons Reference-Counter verlassen. Die
Warnung hilft Nutzern nicht nur besseren Code zu schreiben, sondern erlaubt es
ihnen auch sichereren VM-übergreifenden Code zu schreiben. Um die
VM-übergreifende Kompatibilität noch weiter zu stärken, wurde ein neuer
Warnungstyp vorgeschlagen: CompatibilityWarning.
Die Idee wurde aus einem kürzlich geöffneten CPython-Bug geboren, der von den
PyPy-Entwicklern gefunden wurde. Issue #11455 erklärt ein Problem, bei dem CPython es
einem Nutzer erlaubt einen Typ zu erstellen, dessen __dict__ nicht-String
Schlüssel enthält, was mindestens von PyPy und Jython nicht unterstützt wird.
Idealerweise können Nutzer eine Warnung aktivieren, um solche Fälle zu
entdecken, genauso wie sie es mit ResourceWarning tun.
Eigenständige Standardbibliothek
Jetzt, nachdem die Verlagerung der CPython-Quellen von Subversion nach Mercurial
vollendet ist, wurde die Idee die Standardbibliothek in ein
eigenes Repository auszugliedern, wiederbelebt. Die Entwickler alternativer
Implementierungen sind sehr an dieser Umstellung interessiert, da es ihre
Entwicklungsprozesse sehr vereinfachen würde. Momentan nutzen sie einen Snapshot
der Standardbibliothek von CPython und wenden implementierungsspezifische
Patches darauf an, ersetzen manche C-Erweiterungen mit reinen Python-Versionen
und vieles mehr.
Die Umstellung muss in einem zukünftigen PEP beschrieben werden und einer der
Diskussionspunkte wird sein, wie die Versionierung gehandhabt werden soll. Da
die Bibliothek außerhalb jeder Implementierungen leben wird, ist es
wahrscheinlich, dass sie eine eigene Versionierung bekommt. Und auch zu den
Tests werden ähnliche Gedanken nötig.
Ein weiteres Thema zur Standardbibliothek-Auskopplung waren reine
Python-Implementierungen und ihre entsprechenden C-Erweiterungen. Maciej
Fijalkowski vom PyPy-Projekt erwähnte, dass mit der Zeit einige Module schon
kleine Unterschiede zwischen den C- und Python-Versionen zeigten. Im Laufe der
Diskussion schlug die Gruppe einen strikteren Ansatz beim Ändern dieser Module
vor, um nicht die Nutzung des einen oder des anderen zu bestrafen. Zusätzlich
wurde beschlossen reine Python-Implementierungen zu bevorzugen und
C-Implementierungen nur dann zu erstellt, wenn damit auch eine
Leistungssteigerung erreicht wird.
Moratorium aufgehoben
Mit dem Start der CPython 3.3-Entwicklung wurde das Moratorium der
Sprachveränderungen aufgehoben. Obwohl die Tore geöffnet sind, erwarten wir,
dass die Sprachveränderungen konservativ ausfallen und es wird versucht die
Änderungsrate zu verlangsamen, um es alternativen Implementierungen weiterhin zu
ermöglichen aufzuschließen. Auch wenn noch keine zur 3.x Linie aufgeschlossen
hat, haben PyPy und IronPython es wegen des Moratoriums geschafft Kompatibilität
zu 2.7 zu erreichen und IronPython ist auf dem Weg zu Python 3.x.
Was für Python 3.3 erwartete Sprachveränderungen angeht, kann man erwarten,
dass PEP 380 akzeptiert wird. Das
PEP führt eine neue yield from <expr> Syntax ein, die einem Generator
erlaubt zu einem anderen Generator zu yield-en. Andere Sprachveränderungen
werden in der nahen Zukunft nicht erwartet.
Attribute für Exceptions
Das nächste Thema war eine kurze Diskussion, dass Exceptions bessere
Attribute bereitstellen sollten, anstatt Nutzer zu zwingen sich auf
String-Meldungen zu verlassen. Zum Beispiel wäre es bei einem ImportError
sinnvoll einen einfachen Zugriff auf den fehlgeschlagenen Import zu haben,
anstatt die Meldung danach zu untersuchen.
Die Implementierung wird sich wahrscheinlich auf ein keyword-only Argument bei
der Initialisierung eines Exception-Objekts stützen und es existiert schon ein
Patch für den Fall von ImportError.
Contributor-Agreements
Mitarbeiter-Vereinbarungen wurden ebenfalls erwähnt und eine Form elektronischer
Vereinbarung ist unterwegs. Googles Individual Contributor Agreement war eine von mehreren
Inspirationsquellen für die Ausarbeitung des neuen Systems. Das Thema wurde
lange diskutiert und viele Leute erwarten eine Lösung für das
Problem. Zusätzlich wurden Untersuchungen angestellt, um sicherzustellen, dass
ein Wechsel zu einer elektronischen Vereinbarung auch in nicht-US
Rechtsprechungen gilt.
Google Summer of Code
Martin von Löwis nahm sich kurz Zeit, um ein weiteres Jahr des "Google Summer of
Code" unter dem Dach der PSF einzuleiten. Entwickler sind dazu ermuntert, nicht
nur als Mentor zu arbeiten, sondern auch Projekte vorzuschlagen, an denen
Studenten arbeiten könnten -- der Vorschlag eines Projekts heißt aber nicht,
dass man es auch als Mentor betreuen muss. Wenn Du daran interessiert bist, auf
irgendeine Art und Weise zu helfen, schau mal bei dem Call for Projects and
Mentors der PSF
vorbei.
Distutils
Distutils2 kam auf und Tarek Ziadé erwähnte, dass das Ziel ihres Sprints die
Vollendung des Python 3-Ports und die Vorbereitung für die spätere Rückführung
in die Standardbibliothek sei. Zusätzlich kommt damit ein neuer Name:
packaging. Das packaging-Team plant auch ein eigenständiges Paket,
immer noch unter dem Namen Distutils2, um Python 2.4 bis 3.2 zu unterstützen.
Das Ergebnis des packaging-Sprints, der einer der größeren PyCon-Sprints war,
war sehr erfolgreich. Die momentanen Ergebnisse, die auf den Merge zurück in die
Standardbibliothek warten, gibt es bei Bitbucket.
Die Zukunft alternativer VMs
Die IronPython-Vertreter haben ihre Zukunftspläne erwähnt und ein 3.x-Release
ist das nächste auf ihrem Plan. Sie verkündeten ihr 2.7.0-Release auf der PyCon,
ihr erstes Community-basiertes Release, seit Microsoft das Projekt aus der Hand
gab, und sie werden sich in den nächsten Monaten in Richtung 3.x aufmachen.
Jython brachte kürzlich ein 2.5.2-Release heraus und das Team begann mit der
Planung eines 2.6-Release. Manche erwähnten, dass sie direkt zu 2.7 springen
sollten, da die Unterschiede zwischen 2.6 und 2.7 nicht sonderlich groß sind,
aber es könnte dann auch länger bis zu einem ersten Release dauern. "Release
early, Release often" (Veröffentliche früh, Veröffentliche oft) war einer der
Zitate, die aus dem Gespräch herausdrangen und es könnte sogar klappen direkt
von 2.6 auf 3.x umzusteigen und erst danach die Unterschiede zwischen 2.6 und
2.7 zu betrachten.
Fördergelder
Nach den Planungsgesprächen zu 3.x war das Thema die Förderung von
Entwicklungsarbeit und wie man damit den Weg mancher alternativer
Implementierungen zu 3.x beschleunigen könnte. Geld ist verfügbar, aber es muss
erst ein Antrag an die PSF gerichtet werden, bevor irgendetwas besprochen werden
kann. Wer an Fördergeldern für diese Bemühungen interessiert ist, sollte die PSF
kontaktieren.
"Baseline" Python
Jim Fulton startete eine Diskussion über etwas, das er "Baseline" Python
nannte. Er machte schlechte Erfahrungen beim Deployment von Python-Anwendungen,
da die System-Python-Version unvorhersehbar umfangreich ist und damit ein
schwieriges Ziel darstellt. Da Fedora und Debian-/Ubuntu-Paket-Experten zur Hand
waren, war es möglich einen Einblick in den Stand der Dinge zu bekommen.
Bei Fedora steht bei der Basisinstallation von Python die Live CD im Blick,
darum ist es eine sehr minimale Installation mit wenigen Abhängigkeiten, im
Grunde nur das allernötigste, damit das System überhaupt funktioniert.
Zusätzliche Unterschiede gibt es bei den Verzeichnislayouts, das Entfernen von
Modulen der Standardbibliothek wie distutils oder dass die Distribution
veraltete Bibliotheken anbietet.
Eine scharf umrissene Lösung fand sich nicht direkt, aber die zuständigen
Personen werden weiter an dem Problem arbeiten.
3.3 Features
Es kamen manche Gedanken für 3.3 Features herauf, darunter zwei PEPs.
PEP 382, das Namensraum-Pakete
abdeckt, sollte an einem Zeitpunkt des Zyklus auftauchen. Es wurde auch schon im
Zuge des distutils-Merge angesprochen.
PEP 393, das eine flexible
String-Repräsentation definiert, stand ebenfalls zur Diskussion und
interessierte schon manche Studenten als GSoC-Projekt. Zusammen mit der
Implementierung wird etwas Aufwand bei den Leistungs- und
Speichercharakteristiken der neuen Interna nötig sein, um zu überprüfen, ob sie
akzeptabel sind.
Unladen Swallow
Unladen Swallow "schläft" momentan und wird so keinen Einzug in CPython 3.3
finden. Um weiteren Fortschritt zu machen, müssen mehrere Champions gefunden
werden, da sich die Domänenexperten nicht darum kümmern können. Während der
Diskussion wurde erneut erwähnt, dass, sollte es an Geldern mangeln, um Unladen
Swallow auf das nächste Level zu bringen, Interessierte sich bei der PSF melden.
Obwohl Unladen Swallow schläft und eine ungewisse Zukunft hat, hat das Projekt
einen großen Dienst für Python und die gesamte Open Source Gemeinde
geleistet. Die von Unladen Swallow genutzte Benchmark Suite ist beispielsweise
sehr hilfreich beim Testen alternativer Implementierungen. Zusätzlich haben die
Unladen Swallow-Entwickler mit Beiträgen zu LLVM und Clang diesen Projekten
ebenfalls geholfen.
Zwei weitere Leistungsideen wurden ebenfalls kurz angesprochen, darunter Dave
Malcolms "function inlining" Vorschlag. Martin von Löwis erwähnte ein
JIT-Erweiterungsmodul, an dem er arbeitet, obwohl die PyPy-Entwickler Zweifel
hatten ob der Effizienz eines solchen JITs.
Eine Bresche für asynchrone Frameworks schlagen
Am Ende des Tages fand eine Diskussion um eine teilweise Integration von Twisted
in die Standardbibliothek statt. Die Grundidee ist, eine Alternative zu
asyncore zu schaffen, die eine einfacheren Übergang zu Twisted und anderen
asynchronen Programmierungsframeworks bietet.
Das Vorgehen wird in einem anstehenden PEP noch ausgebreitet, das einen Zweck
ähnlich der WSGI-Referenzimplementierung verfolgt, aber für asynchrone
Ereignisschleifen. Zusammen mit den PEP-Autoren wird es nötig sein, dass das
Twisted-Projekt und andere Einsatz zeigen, um sicherzustellen, dass jeder auf
demselben Stand ist.
