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.
Performance Benchmark Site
Das PyPy Speed Center hat mit dem Zeigen von PyPys Performance-Ergebnissen großartige Arbeit geleistet und es gab einige Diskussion um das bereitstellen einer ähnlichen Seite bei python.org, möglicherweise performance.python.org, bei dem alle VMs teilnehmen könnten. Zusätzlich zu Geschwindigkeit-Benchmarks sollten andere Benchmarks, wie Speicherverbrauch, Testerfolg und Sprachkompatibilität, berücksichtigt werden. Es wird aber einiger Aufwand nötig sein, um die Infrastruktur so anzupassen, dass sie mit mehreren Implementierungen arbeitet, da momentan nur PyPy mit CPython verglichen wird.
Zur Umsetzung des "Speed Center", kam es ins Gespräch Hochleistungsmaschinen in das Open Source Lab bei der Oregon State University zu stellen, bei dem Allison Randal beteiligt ist. Jesse Noller erwähnte Anstrengungen Hardware zu beschaffen, um sie in das Lab zu stellen -- Spenden sind willkommen!
Wenn Du oder Deine Organisation interessiert sind für diesen Zweck zu spenden, kontaktiere bitte die Python Software Foundation und schau auf unsere Spendenseite.
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.
Mehr Informationen
Mehr Informationen gibt es bei CPython-Entwickler Nick Coghlans rough notes und highlights.
