Python Insider DE

Meet the Team: Brett Cannon

2011-10-09T15:06:00.000+02:00

Dieser Post ist Teil der "Meet the Team" Serie, die kurz das Python-Kernentwickler-Team vorstellen soll.

Name:	Brett Cannon
Standort:	San Francisco, Kalifornien, USA
Homepage:	https://profiles.google.com/bcannon
Blog:	http://sayspy.blogspot.com

Wie lange nutzt Du schon Python?

Seit dem Herbst 2000.

Wie lange trägst Du schon zum Kern bei?

Seit April 2003 (kurz nach der PyCon 2003).

Wie wurdest du Kernentwickler? Erinnerst Du dich an deinen ersten Beitrag?

Ich wurde ein Kernentwickler, weil ich ständig Leute genervt habe, ob sie für mich Patches commiten würden (ein Trick der heute nicht mehr so gut funktioniert; ein Vorteil, dass ich eingestiegen bin, bevor die Popularität von Python in 2003/2004 einen Sprung machte). Von Anfang 2002 an belebte ich die "Python-Dev Summaries" neu (was ungefähr 2,5 Jahre anhielt). Beim Schreiben der Summaries stieß ich desöfteren auf kleine Probleme, die behoben werden mussten. Da ich schon regelmäßig auf python-dev redete, fragte ich einfach Leute, ob sie meine Patches überprüfen und für mich commiten würden. Eines Tages fragte mich Guido, warum ich nicht selbst commitet habe und ich sagte, dass ich keine Rechte dazu hätte und er antwortete mehr oder weniger so: "jetzt hast du sie".

In meinem ersten Commit (Changeset 28686) behob ich ein Problem beim Escapen von Zeichenketten in time.strptime() (was auch mein erster Beitrag zu Python überhaupt war).

An welchen Teilen von Python arbeitest Du jetzt?

Ich konzentriere mich normalerweise auf die Import-Maschinerie und darum, dass Python als Sprache auf allen VM gut funktioniert.

Was machst Du mit Python, wenn Du nicht gerade am Python-Kern schraubst?

Ich habe es geschafft ein bisschen Python in meiner Doktorarbeit unterzubringen und habe serverseitigen Code in Python implementiert. Abseits davon versuche ich in allen meinen privaten Projekten so viel Python wie möglich zu verwenden. Mein zukünftiger Job bei Google wird auch großteils aus Python bestehen.

Was macht Du, wenn Du nicht gerade programmierst?

Ich bin ein ziemlicher Film-Junkie mit einer Prise ausgewählter Teile TV (meinen Fernseher im Sommer 2000 an eine Hitzewelle zu verlieren war eines der besten Dinge, die mir unbeabsichtigt passierten; meine Frau zu heiraten war das beste das ich absichtlich getan habe =). Daneben lese ich viel: Hauptsächlich Magazine und Websites, aber ich habe immer auch ein Buch, das ich lese.

Englische Version

Meet the Team: Michael Foord

2011-08-21T15:37:00.000+02:00

Dieser Post ist Teil der "Meet the Team" Serie, die kurz das Python-Kernentwickler-Team vorstellen soll.

Name:	Michael Foord
Standort:	Northampton UK
Homepage:	http://www.voidspace.org.uk/

Wie lange nutzt Du schon Python?

Ich fing mit Python 2002 als Hobby an und arbeitete ab 2006 Vollzeit mit Python. Den Anfang mit Python machte ich mit einer Gruppe von Leuten, die Informationen aus einem Play-By-Email-Spiel aggregieren wollten. Wir hatten alle seit einer Weile nicht programmiert und hatten uns gerade auf Smalltalk geeinigt, als uns jemand vorschlug Python zu versuchen. Ich verliebte mich schnell in Python.

Wie lange trägst Du schon zum Kern bei?

Seit der PyCon 2009. Ursprünglich wegen meiner Beteiligung an IronPython.

Wie wurdest du Kernentwickler? Erinnerst Du dich an deinen ersten Beitrag?

Während der PyCon 2009 Sprints arbeitete ich mit Gregory Smith, auch Kern-Entwickler, um ein paar Verbesserungen in unittest zu integrieren, die von Google beigesteuert wurden.

An welchen Teilen von Python arbeitest Du jetzt?

Nach der anfänglichen Arbeit an unittest während des PyCon Sprints nahm ich mich anderer Probleme und Verbesserungen von unittest an, das keinen Maintainer hatte. Ich wurde der Maintainer von unittest, aber ich arbeite auch an anderen Teilen der Standardbibliothek.

Ich unterstütze Python auch auf andere Weise, so passe ich auf Planet Python auf, bin ein PSF-Mitglied, helfe mit dem python.org Webmaster-Alias aus und so weiter.

Was machst Du mit Python, wenn Du nicht gerade am Python-Kern schraubst?

Ich verdiene mein Geld, indem ich Web-Entwicklung für Canonical mache. Ich arbeite an Teilen der Web-Dienste-Infrastruktur rund um die Canonical-Website und auch an ein paar Diensten, die mit Ubuntu selbst integriert sind. Das macht Spaß und es ist ein tolles Team.

In meiner Freizeit arbeite ich an Projekten wie unittest2 (ein Backport der Verbesserungen an unittest für andere Plattformen) mock (eine Bibliothek zum Testen, die Mock-Objekte bietet und Monkey-Patching in Tests unterstützt) und noch ein paar mehr kleinere Sachen.

Ich möchte mehr schreiben, aber da ich den größten Teil von zwei Jahren dem Schreiben von "IronPython in Action" widmete, glaube ich nicht, dass ich mich bald an ein größeres Schreibprojekt wagen werde.

Was macht Du, wenn Du nicht gerade programmierst?

Ich engagiere mich sehr in einer Kirche in Northampton (GB), was eine Menge meiner Zeit kostet und ich helfe bei der Verwaltung von einer Wohltätigkeitsorganisation, die von uns betrieben wird. Das ist ein Grund warum es gut ist, für Canonical zu arbeiten: Ich kann von Zuhause arbeiten. Da ich hier Wurzeln geschlagen habe, werde ich hier nicht wegziehen (Ich bleibe sicher nicht wegen dem Wetter). Natürlich gibt es nicht viel Python-Programmierung in Northampton. Meinen ersten Vollzeit-Job als Programmierer hatte ich mit einem erstaunlichen Team in London, zwei Stunden Pendelstrecke von Tür zu Tür, hin und zurück. Ich bewältigte das vier Jahre lang und genoss den Job sehr, aber da ich dem Pendeln nun entkommen bin, werde ich wahrscheinlich nicht zurückgehen.

Ich genieße es auch auf der XBox zu spielen. Unglücklicherweise kann mich ein Spiel wochenlang fesseln, wenn ich eines finde, das ich mag. Aus genau diesem Grund habe ich auch World of Warcraft und Eve Online gemieden... Ich organisiere auch ein monatliches Geek Meet in Northampton. Es gibt nicht genügend Python Programmierer für eine Python Usergroup, aber wir haben eine gute Auswahl von Geeks aller Art. Normalerweise treffen wir uns einfach in einem Pub und quatschen oder zeigen unsere neusten Gadgets.

Ein Python-Starter für Windows

2011-08-17T22:13:00.000+02:00

Mark Hammond (Autor von pywin32 und seit langem Unterstützer von Python unter Windows) hat PEP 397 geschrieben, das einen neuen Starter für Python unter Windows beschreibt. Vinay Sanjip (Autor des logging-Moduls der Standardbibliothek) hat kürzlich eine Implementierung des Starters erstellt: Sie ist unter https://bitbucket.org/vinay.sajip/pylauncher/downloads verfügbar.

Der Starter erlaubt Python-Skripten (.py- und .pyw-Dateien) unter Windows die Version von Python festzulegen, die benutzt werden soll, und erlaubt damit die simultane Benutzung von Python 2 und 3.

Windows-Benutzer sollten sich überlegen, den Starter herunterzuladen und zu testen, um den Python-Entwicklern zu helfen eventuell verbleibende Probleme auszubügeln. Der Starter ist als eigenständige Anwendung paketiert und wird die momentan verfügbaren Python-Versionen unterstützen. Es ist geplant den Starter, sobald er fertiggestellt ist, als Teil von Python 3.3 auszuliefern (er wird aber noch als eigenständiges Programm für Nutzer früherer Versionen verfügbar bleiben).

Zwei Versionen des Starters sind verfügbar: launcher.msi, das in das Programme-Verzeichnis installiert; und launchsys.msi, das in Windows' System32-Verzeichnis installiert. (Es gibt auch 64-Bit-Versionen für 64-Bit-Windows-Versionen).

Ein Paar Details zum Starter

Die komplette Spezifikation des Starter-Verhaltens wird in PEP 397 beschrieben. Die wesentlichen Grundlagen sind:

Der Starter beinhaltet zwei ausführbare Programme — py.exe (die Konsolen-Version) und pyw.exe (die GUI-Version).
Der Starter ist als Handler für .py (Konsole) und .pyw (GUI) Dateiendungen registriert.
Beim Ausführen von Skripten sucht der Starter nach einer Unix-mäßigen #! (Shebang) Zeile im Skript. Es erkennt die Namen python (Standard-Python des Systems) python2 (Standard-Python2-Version) und python3 (Standard-Python3-Version). Die genauen Details können einfach pro Nutzer oder pro System angepasst werden.
Alleine benutzt, startet py.exe den interaktiven Python-Interpreter. Kommandozeilen-Schalter werden in der Art unterstützt, dass py -2 Python 2, py -3 Python 3 und py die Standard-Version startet.

Hinweise zur Benutzung

Ist er installiert, verknüpft sich der Starter selbstständig mit .py- und .pyw-Skripten. Tut man nichts entsprechendes, werden die Skripte mit dem Standard-Python-Interpreter der Maschine ausgeführt, man merkt also keine Veränderung. Nutzt man die Konsole sehr häufig, will man wahrscheinlich .py in die PATHEXT-Variable aufnehmen, damit Skripte nicht in einer separaten Konsole ausgeführt werden.

Um festzulegen, dass ein Skript Python 2 nutzen muss, fügt man einfach folgendes als erste Zeile zum Skript hinzu:

#!/usr/bin/env python2

Will man dagegen festlegen, dass ein Skript Python 3 nutzen muss, fügt man als erste Zeile:

#!/usr/bin/env python3

hinzu.

Man kann auch den Python-Interpreter mit folgenden Befehlen starten:

# Standard-Python-Version
py
# Python 2
py -2
# Python 3
py -3

Damit das funktioniert, muss sich py.exe im Suchpfad befinden. Dies geschieht automatisch mit der launchsys-Version des Installers. Bei der Benutzung von launcher.msi muss das Installationsverzeichnis (C:\\Programme\Python Launcher) manuell zu PATH hinzugefügt werden.

Literaturhinweise

Die folgenden Email-Threads auf python-dev decken ein paar Schlüsseldiskussionen ab:

Marks erste Ankündigung des PEP-Entwurfs: http://mail.python.org/pipermail/python-dev/2011-March/109509.html
Der zweite Entwurf des PEP: http://mail.python.org/pipermail/python-dev/2011-March/109786.html
Vinays erste Anfrage bezüglich einer C-Implementierung des Starters: http://mail.python.org/pipermail/python-dev/2011-March/109786.html
Vinays Ankündigung seiner C-Implementierung: http://mail.python.org/pipermail/python-dev/2011-July/112184.html
Vinays Ruf nach Testern: http://mail.python.org/pipermail/python-dev/2011-July/112251.html

Englische Version

CPython 3.2.1 Released

2011-08-12T21:40:00.001+02:00

Im Namen des python-dev Teams, hat Release Manager Georg Brandl das finale Release von CPython 3.2.1 bekannt gegeben. Windows Installer und Tarballs sind seit dem 10. Juli bereit, also Bitte überlegt zu diesem Release zu wechseln.

Das What's New Dokument listet alle seit 3.2 neuen Features auf und die Datei Misc/NEWS in der Quellcodedistribution enthält eine Liste der Fehlerbehebungen.

Falls Du ein Problem mit dieser oder einer anderen Version hast: Melde sie bitte auf http://bugs.python.org/.

Englische Version

3.2.1 Release Candidate 2 veröffentlicht

2011-08-12T21:40:00.000+02:00

Nach den zahlreichen Veröffentlichungen im Juni, ist der zweite Release Candidate der 3.2.1-Reihe nun bereit. Seit dem ersten Release Candidate am 15. Mai wurden über 40 Probleme behoben. Wir rufen jeden dazu auf, seine Projekte mit diesem RC zu testen, um einen letzten Blick vor der endgültigen Veröffentlichung von 3.2.1 zu bekommen.

Was wurde behoben?

I/O

#1195 verbrachte ein paar Jahre ohne Korrektur, aber eine kleine Ergänzung, um Fehler vor dem Aufruf von fgets zu beseitigen, löst das Problem beim Unterbrechen von sys.stdin.read() mit STRG-D innerhalb von input(). Daneben wurde das io System in #12175 aufgeräumt: readall() gibt nun None zurück, wenn read() None zurückgibt und nun wird ein ValueError verursacht, wenn eine Datei nicht geöffnet werden kann.

Auch wenn dies nicht neu für RC2 ist, stellt #11272 eine wichtige Fehlerkorrektur an input() dar -- das Entfernen des \r am Ende. Das Problem wurde schon viele Male berichtet und betrifft viele Leute (z.B. beim distutils Upload-Befehl), 3.2.1 sollte also dieses Problem beheben.

Windows

3.2.0 brachte ein neues Feature für Windows: os.symlink Unterstützung. Mit diesem Feature kam #12084: os.stat wertete Windows-Symlinks falsch aus, deshalb wurden die Implementierungen der zahlreichen stat Funktionen korrigiert.

Ein Nutzer bemerkte, dass os.path.isdir langsam war, wofür die Tatsache, dass es auf os.stat basierte, beitrug, vor allem beim Auswerten von Symlinks (die generell zweimal so langsam wie normale Dateien sind). Während os.path.isdir niemandes Flaschenhals ist, wird es sehr oft beim Starten des Interpreters aufgerufen, darum beschleunigt die Änderung in #11583 GetFileAttributes den Start ein wenig.

subprocess

Das Erstellen von Popen-Objekten mit unerwarteten Argumenten erzeugte einen AttributeError, was aber in #12085 berichtet wurde und vom Meldenden selbst behoben wurde. Wegen einer Veränderung in 3.2.0 behandelte Popen leere Umgebungsvariablen falsch, speziell das env-Argument. #12383 wurde für das Problem erstellt und umgehend behoben.

... und mehr!

Die komplette Liste der Veränderungen in 3.2.1 RC2 gibt es im Changelog und lade RC2 nun herunter!

Wie immer: Bitte berichte jegliche Probleme, die Du findest auf dem Bugtracker. Wir schätzen Deine Hilfe bei der Entwicklung großartiger Python-Versionen!

Englische Version

Veröffentlichungen Juni 2011

2011-08-12T15:54:00.002+02:00

Dieser Juni ist ein großer Monat für Python-Veröffentlichungen: Es kommt ein Update für alle aktiven Zweige.

2.6.7

Mit 2.6.7 ist eine reine Quellcode-Veröffentlichung von Python verfügbar, die drei Sicherheitsprobleme behebt. Da sich die 2.6-Reihe im Sicherheits-Modus befindet, werden diese Veröffentlichungen bis Oktober 2013 nur passieren, wenn es nötig ist und auch nur als Quellcode. Wenn Du binäre Installer benötigst, solltest Du ein Upgrade zu 2.7 oder 3.2 in Betracht ziehen.

2.6.7 ist die erste Veröffentlichung, die die urllib Verwundbarkeit behebt, über die hier schon berichtet wurde. Zusätzlich wurde eine smptd-DoS- (Issue #9129) und eine SimpleHTTPServer.list_directory-XSS-Verwundbarkeit (Issue #11442) behoben.

2.7.2

Mehr als 150 Bugs wurden in der letzten Minor-Version der 2.x-Reihe, 2.7, seit 2.7.1 im November 2010 behoben. Darunter die in 2.6.7 angesprochenen Sicherheitsprobleme.

Ein paar Absturz-Ursachen wurden behoben: Wenn Python fremd verwalteten Speicher falsch benutzt hat, während er von einem anderen Thread verändert wurde; beim Löschen von __abstractmethods__ aus einer Klasse; Zugriff auf Stellen nach dem Ende von Dateien, die in den Speicher gemappt wurden; und verschiedene andere.

Des Weiteren wurde eine Regression in getpass behoben, die die Behandlung von STRG-C STRG-Z betraf. In multiprocessing wurden auch einige Fehler behoben, z.B. die Behandlung von Windows-Diensten als "frozen executables" und eine Korrektur eines Fehler beim Beenden von multiprocessing.Pool Workern, die zu einer Race Condition führten. mmap wurde so verändert, dass es nun mit Dateigrößen und Offsets größer als 4GB arbeitet, sogar auf 32-Bit Builds, desweiteren wird nun beim Versuch auf nicht-schreibbare Maps zu schreiben ein TypeError statt einem Segmentation Fault verursacht.

Eine komplette Liste der Veränderungen gibt es in der News-Datei von 2.7.2.

3.1.4

3.1.4 ist die letzte Bug-Fix-Veröffentlichung der 3.1.x-Reihe, womit 3.1 in den Sicherheits-Modus übergeht, während 3.2 Python 3 weiterführt. 3.1.4 beinhaltet mehr als 100 Fehlerkorrekturen seit der Veröffentlichung von 3.1.3 im November 2010. Wie bei 2.7.2 werden binäre Installer ab dem 12. Juni bereitgestellt und 3.1.4 ist die erste 3.x-Veröffentlichung, die die unter 2.6.7 aufgelisteten Sicherheitskorrekturen enthält.

3.1.4 behebt einige Probleme mit der Suche von __dir__ in Objekten, Daten nach 2038 in der Windows-Implementierung von os.stat und os.utime und hat ein paar 64-Bit Säuberungen. In der io-Bibliothek gab es ein paar Änderungen bezüglich der Rückgabe von None, wenn nichts gelesen wurde, und dem Verursachen von Ausnahmen an anderen Stellen. ctypes-Callback-Argumente wurden in Windows 64-Bit berichtigt und ein Absturz wurde auch behoben.

Eine komplette Liste der Veränderungen gibt es in der News-Datei von 3.1.4.

3.2.1

3.2.1 befindet sich zur Zeit in der Release-Candidate-Phase, bei der schon eine Runde absolviert wurde und ein zweiter Release-Candidate bald erwartet wird. Wir würden es sehr schätzen, wenn Nutzer von 3.2 diese ausprobieren würden, damit sichergestellt wird, dass alle Probleme behandelt werden, die möglicherweise auftreten. Wenn Bugs auftreten, melde sie bitte auf bugs.python.org.

Neues faulthandler Modul in Python 3.3 hilft bei der Fehlersuche

2011-08-06T13:34:00.000+02:00

Wenn ein Anwender eines Programmes einen Absturz oder einen Hänger meldet, kann man manchmal nur versuchen mehr Informationen zu Ablauf und Umgebung zu sammeln und ein Fehlerszenario zu entwerfen, um diesen zu reproduzieren. Selbst mit einem klaren Anwenderszenario, ist man als Entwickler oft wegen verschiedener Umgebungen -- verschiedene Betriebssysteme, Compiler und anderes -- nicht in der Lage den Fehler zu reproduzieren. Wenn man Glück hat, ist der Anwender in der Lage Debug-Werkzeuge zu installieren, aber meistens muss man darauf warten, dass eine andere Person mehr Informationen zum selben Problem liefert.

Fatale Fehler

Das, in Python 3.3 neue, Modul faulthandler soll bei diesem Problem helfen. faulthandler ermöglicht es den Python Traceback bei einem Fatalen Fehler wie ein Segmentation Fault, Division durch Null, Programmabbruch oder bus error, zu erhalten. Man kann das innerhalb eines Programmes mit faulthandler.enable(), durch Starten von Python mit der Programmoption -X faulthandler oder durch Setzen der Umgebungsvariable PYTHONFAULTHANDLER=1 aktivieren.

Beispielausgabe

Fatal Python error: Segmentation fault

Current thread 0x00007f7babc6b700:
  File "Lib/test/crashers/gc_inspection.py", line 29 in g
  File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault

Timeout

faulthandler kann auch bei Programmhängern Traceback-Informationen liefern. faulthandler.dump_tracebacks_later(timeout) aktiviert einen Timer, nach dessen Ablauf ein Traceback ausgegeben wird. Ein erneuerter Aufruf setzt den Timer zurück. faulthandler.cancel_dump_tracebacks_later() stoppt den Timer. Ausgabe:

Timeout (0:01:00)!
Current thread 0x00007f987d459700:
  File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>

Mit der Option repeat=True wird der Traceback alle timeout Sekunden ausgegeben, mit exit=True wird das Programm unsicher beendet; unsicher bedeutet, dass z.B. Dateien nicht mehr auf die Platte geschrieben werden.

Anwender Signal

Wenn man Zugang zum Computer hat, auf dem das Programm läuft, kann man mit faulthandler.register(signal) einen Signalhandler installieren, sodass ein Traceback ausgegeben wird wenn das Programm das signal erhält. Auf Unix kann man zum Beispiel das Signal SIGUSR1 folgendermaßen an den Prozess mit Prozess-Id pid senden: kill -USR1 <pid>. Auf Windows ist diese Möglichkeit nicht vorhanden. Ausgabe:

Current thread 0x00007fdc3da74700:
  File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>

Eine andere Möglichkeit ist im Programmcode direkt faulthandler.dump_traceback() direkt aufzurufen.

Sicherheitsaspekte und Ausgabedatei

faulthandler ist standardmäßig aus Sicherheitsgründen nicht aktiviert, hauptsächlich weil es den Dateideskriptor sys.stderr speichert und die Traceback-Informationen in diesen schreibt. Wenn die Datei sys.stderr geschlossen wird und der Dateideskriptor vom System neu vergeben wird, kann dies ein Socket, eine Pipe, eine wichtige Datei oder anderes sein. Standardmäßig schreibt faulthandler Traceback-Information in sys.stderr, es ist aber möglich eine andere Datei anzugeben. Mehr dazu in der faulthandler Dokumentation.

Nachinstallierbare Version für ältere Python Versionen

faulthandler ist auch als Zusatzmodul für Python 2.5 bis 3.2 auf PyPI erhältlich. Der Hauptunterschied zwischen dem Python 3.3 Modul und der nachinstaliierbaren Version ist die Implementierung von dump_tracebacks_later(): Python 3.3 verwendet einen Thread mit einem Timeout auf einem Lock, die nachinstaliierbaren Version verwendet SIGALRM und alarm().

Der Timeout des Locks, ein neues Feature in Python 3.3, ist in Microsekunden aufgelöst, wohingegen der alarm() Timer nur in Sekunden angegeben werden kann. Daneben unterbricht das SIGALRM-Signal möglicherweise einen geraden aktiven Systemaufruf, was zu einem EINTR Fehler führt.

Erfolgsgeschichten

Das neue Modul hat bereits geholfen Race Conditions in unseren Buildbots zu finden. Wir hoffen, dass es auch Dir in Deinen Programmen hilft.

Englische Version

Das "Python Core Mentorship"-Programm

2011-08-04T16:07:00.000+02:00

Jesse Noller hat kürzlich die Gründung des Python Core Mentorship-Programms angekündigt. Die Idee hinter dem Programm ist es Programmierer, inklusive Studenten und Entwickler anderer Projekte, mit erfahrenen Mitarbeitern zusammenzubringen, die ihnen als Mentoren den Einstieg in die Python-Kernentwicklung erleichtern sollen.

Mitarbeiter gesucht

Die Mentoren werden Leuten helfen, ganz egal auf welchem Kenntnisstand sie sind, indem sie Fragen beantworten und Anleitung geben, auf freundliche Art und Weise. Die Mitarbeiter werden während der ganzen Mitarbeit begleitet, was Diskussionen auf den verwandten Mailinglisten, dem Bug-Tracker, Mercurial, Code Reviews und noch viel mehr mit einschließt.

Frühe Erfolge

Das Programm ist schon jetzt erfolgreich und die Teilnehmer haben schon aktiv viele Patches beigesteuert. Es gab auch schon viele konstruktive Diskussionen auf der Mailingliste, die Leuten mit verschiedenen Problemen in die richtige Richtung führten.

Verhaltenskodex

Das Programm hat einen Verhaltenskodex, der auf der Website erklärt wird. Er soll den Sorgen begegnen, die viele neue Mitarbeiter haben, wenn sie es mit erfahrenen Entwicklern und Mitarbeiter-Mailinglisten im Allgemeinen zu tun haben. Jesse und die anderen Mentoren hoffen, dass dieses Programm auf lange Zeit anderen Projekten als Modell dienen kann und nicht nur Python-Core nützt. Sie wollen mit dem Programm auch die Vielfalt der Mitarbeiter an Python vergrößern.

Einschreiben

Das Programm wird über die Mailingliste betrieben und ihm ist eine klare und prägnante Website gewidmet. Wenn Du beitreten möchtest, um Fragen zu stellen und den Weg zur Mitarbeit am Kern von Python beschreiten willst -- oder sogar ein erfahrener Entwickler (sogar erfahren mit Python-Core) bist, der Fragen stellen will, aber nicht auf anderen Listen fragen willst -- dann ist dies eine ausgezeichnete Gelegenheit aufzuspringen, zu fragen und erste Erfahrungen mit Python-Core zu sammeln.

Englische Version

Übersetzungen ins Rumänische und zu Chinesischen Kurzzeichen

2011-07-30T00:29:00.003+02:00

Das Python Insider-Team freut sich heute zwei neue Blogs anzukündigen. Übersetzer für Rumänisch und Chinesische Kurzzeichen sind dem Übersetzungsprojekt beigetreten und haben schon damit angefangen die aufgelaufenen Posts zu veröffentlichen. Wie auch die anderen Übersetzungen, werden diese Übersetzungen den Posts auf Python Insider etwas hinterherhinken.

Englische Version

Übersetzungen ins Portugiesische, Deutsche, Koreanische und zu Chinesischen Langzeichen

2011-07-30T00:29:00.002+02:00

Das Python Insider Übersetzungsprojekt wächst weiter! Heute starten wir die Portugiesische, Deutsche, Koreanische und die Chinesische Langzeichen Version des Blogs. Die Übersetzer haben schon damit angefangen die aufgelaufenen Posts zu veröffentlichen und wie auch die anderen Übersetzungen, werden diese Übersetzungen den Posts auf Python Insider etwas hinterherhinken.

Englische Version

Jython migriert zu Mercurial

2011-07-27T23:19:00.000+02:00

Jython ist endlich von Subversion zu Mercurial migriert. Dies lief schon seit einiger Zeit, aber unglücklicherweise hatten wir ein schwieriges Subversion-Repository, darum war einiger Aufwand nötig, um es sauber zu einem anderen Versionskontrollsystem zu konvertieren.

Das neue offizielle Jython-Repository ist nun bei

http://hg.python.org/jython

beheimatet, zusammen mit einem BitBucket Mirror zum einfachen forken.

Es gibt auch ein größeres Repository mit laufenden Feature-Zweigen (zu Mercurial Bookmarks konvertiert) bei http://hg.python.org/jython-fullhistory , das aber nur lesbar ist.

Mercurial macht es sogar noch leichter an Jython mitzuarbeiten: Forke das Repository und hilf uns Jython 2.6 zu bauen!

Englische Version

Python 3.3 wird Unterstützung für OS/2, Windows 2000 und VMS einstellen

2011-07-23T19:37:00.000+02:00

Hin und wieder ist es an der Zeit die Liste der unterstützten Betriebssysteme so zurückzuschneiden, dass sie mit der tatsächlichen Benutzung übereinstimmt. Daneben ist auch die Menge der beisteuernden Entwickler auf einer Plattform wichtig, da jemand die Entwicklungsarbeit leisten muss, um beim Release die Qualität zu sichern. Andere Faktoren, wie das Alter eines Betriebssystems und sein Ballast für die zukünftige Entwicklung haben auch einen Einfluss auf diese Liste.

Victor Stinner hat kürzlich vorgeschlagen die Unterstützung von CPython für OS/2 und VMS einzustellen, ein Jahr nach seiner ursprünglichen Frage nach der OS/2-Unterstützung. Victors ursprüngliche Frage kam zur Zeit seiner unermüdlichen Unicode-Arbeit, genauer für ein Problem mit os.execvpe(), um Umgebungsvariablen über den PEP 383-"surrogateescape"-Handler zu unterstützen. OS/2 und VMS haben zur Zeit keine Repräsentation innerhalb des Entwicklerteams und erhalten damit keine Tests während dem Release-Prozess.

Das Schreiben dieses Eintrags brachte mich zum Nachdenken über eine vorherige Diskussion über das Entfernen von Windows 2000, das auf der Strecke zu bleiben schien. System, die COMSPEC auf command.com setzen, schienen damals auch auf dem Hackbrett zu liegen. Mittlerweile haben sich beide zu OS/2 und VMS gesellt. Windows 2000 wird entfernt, um die Entwicklungsarbeit einfacher zu machen, da es die Last nimmt, sich um die Legacy-API eines Betriebssystems zu kümmern, das 2010 sein "end-of-life" erreicht hat.

Um die Unterstützung für diese Systeme zu entfernen, haben Victor und ich uns daran gemacht PEP 11 zu aktualisieren.

PEP 11

Dieses PEP umreißt die Betriebssysteme, die nicht mehr unterstützt werden, und erklärt wie man ein System zu dieser Liste hinzufügt.

Sobald es entschieden ist, dass ein Betriebssystem entfernt werden kann, wird es formal als nicht-unterstützt angekündigt. Diese Ankündigung gilt traditionell für die Version, an der gerade entwickelt wird, also gilt der Wegfall der Unterstützung für OS/2, Windows 2000 und VMS ab Python 3.3.

Das erste Stadium läuft so ziemlich von selbst, es ist mehr das Heben einer weißen Flagge. Es ist ein Signal, dass es keinen mehr gibt, der den Code wartet und die Qualität eines Release sicherstellt. Es können Veränderungen am Kompilierungs- und Installationsprozess gemacht werden, um Nutzer zu informieren, dass ihre Plattform nicht unterstützt wird. Und dem "What's New"-Dokument wird eine Bemerkung hinzugefügt, die die neuen nicht mehr unterstützten Plattformen auflistet.

Nach einem Releasezyklus, in dem die Plattform nicht unterstützt ist, ist der Code in der nachfolgenden Version Freiwild und kann entfernt werden. In diesem Fall kann der Code in 3.4 entfernt werden. Der Code wird möglicherweise nicht komplett entfernt, aber Entwickler, die während ihrer normalen Arbeit daran vorbeikommen können jegliche #ifdef-Blöcke, configure-Abschnitte oder veralteten Code entfernen.

Was Du tun kannst

Wenn du ein OS/2- oder VMS-Nutzer bist, dann gibt es ein paar Möglichkeiten, die du ausschöpfen kannst, um deine Plattform zu retten.

Werde Maintainer

Nichts ist besser für die Unterstützung als ein aktiver Entwickler. Andrew MacIntyre war seit einiger Zeit der OS/2-Maintainer und sagte zu Victors erster Anfrage, dass OS/2 in der Unterstützung von Unicode hinterherhinkt, dies ist also sicherlich ein Gebiet auf das man sich konzentrieren muss. VMS scheint einen gewissen Grad von Unterstützung von Außen durch http://www.vmspython.org zu haben, aber wie schon in Issue 11918 diskutiert wurde, muss sich jemand bereiterklären um weiterhin VMS-Unterstützung Upstream (d.h. innerhalb von CPython) zu haben.

Wenn Du daran interessiert bist, eine der beiden Plattformen zu übernehmen, dann schau dir den Developer's Guide an, um die aktuellen Entwicklungsprozesse kennenzulernen.

Steuer einen Build-Slave bei

Mit einem aktiven Entwickler, hat eine Plattform bessere Chancen zu überleben. Mit einem Build-Slave, hat eine Plattform sogar noch bessere Chancen, nicht nur zu überleben, sondern auch um eine gewisse Qualität zu gewährleisten.

Python benutzt Buildbot für Continuous Integration und es gibt momentan Build-Slaves für Linux, Mac, Windows und Open Indiana (Solaris) für verschiedene Versionen, Architekturen und Konfigurationen. Wenn Du in der Lage bist eine Maschine für die Build-Flotte für OS/2 oder VMS zu spenden, könntest Du ermöglichen, dass diese Plattformen diesselbe Aufmerksamkeit bekommen, wie sie auch verbreitetere Plattformen bekommen.

Wenn Du entwender Zeit oder Hardware beisteuern kannst, um OS/2 und VMS zu retten, melde Dich auf der python-dev-Mailingliste, um die Bemühungen zu koordinieren.

Englische Version

Python Insider Übersetzungsprojekt

2011-07-17T17:29:00.000+02:00

Wir denken, dass der Inhalt dieses Blogs für die gesamte Python-Community nützlich ist, darum hat für uns das Erreichen möglichst vieler Leser eine hohe Priorität. Um unsere Reichweite zu erhöhen, haben wir ein Team von Übersetzern um uns geschart, damit wir parallel Ausgaben dieses Blogs in anderen Sprachen erstellen können. Heute starten wir zwei Übersetzungen: Japanisch und Spanisch.

Die Übersetzungen werden den Posts auf Python Insider etwas hinterherhinken, aber es wird versucht sie mehr oder weniger aktuell zu halten.

Hilfe gesucht

Das Übersetzungsteam ist immer noch sehr klein, darum suchen wir nach weiteren Helfern. Wir brauchen Leute, die an den bestehenden Übersetzungen arbeiten oder uns helfen neue Übersetzungen zu starten. Wenn Du uns auf eine dieser Arten helfen kannst, kontaktiere Doug Hellmann (doug dot hellmann at gmail -- englischsprachig).

Englische Version

Meet the Team: Brian Curtin

2011-07-17T17:27:00.000+02:00

Dieser Post ist Teil der "Meet the Team" Serie, die kurz das Python-Kernentwickler-Team vorstellen soll.

Name:	Brian Curtin
Standort:	Chicago, USA
Homepage:	http://blog.briancurtin.com/

Wie lange nutzt Du schon Python?

Täglich seit 6 Jahren. Davor nutzte ich Python schon gelegentlich für eine Klasse im College und in einem Sommer-Praktikum.

Wie lange trägst Du schon zum Kern bei?

Knapp über ein Jahr. Am 24. März war ich ein Jahr bei der Gruppe.

Wie wurdest Du Kernentwickler? Erinnerst Du dich an deinen ersten Beitrag?

Ich habe angefangen, nachdem ich einen Fehler in der Dokumentation bemerkt habe, als ich auf der Arbeit ein Erweiterungsmodul geschrieben habe, dann habe ich einen einfachen Patch eingereicht und Georg Brandl hat ihn fast augenblicklich aufgenommen. Nach diesem schnellen Erfolg und nachdem ich mir eine frische Version des Quellcodes geholt habe, wollte ich eintauchen und mehr über die Module lernen, die ich benutze, und endete damit einen Patch zu schreiben, der zipfile "context manager"-Unterstützung hinzufügt.

Meine ersten Paar Beiträge waren Ausbesserungen der Dokumentation, um es für den Anfang einfach zu halten. Mein erster Quellcode-Beitrag fügte dem winreg-Modul ein paar Features hinzu und erweiterte die Test-Abdeckung.

An welchen Teilen von Python arbeitest Du jetzt?

Als einer der paar Windows-Benutzer, die bei der CPython-Entwicklung beteiligt sind, versuche ich ein Auge auf alle Probleme zu haben, die Windows-Benutzer betreffen. Deshalb hatte ich schon Gelegenheit an vielen Modulen der Standardbibliothek zu arbeiten, unter anderem Modulen, die ich noch nie benutzt habe. Ich habe noch nicht viel am Interpreter selbst gearbeitet, aber ich versuche das zu ändern.

Was machst Du mit Python, wenn Du nicht gerade am Python-Kern schraubst?

Ich baue verschiedene Test-Werkzeuge für eine Handels-Datenbank, die in C++ geschrieben ist. Dort gibt es ein Erweiterungsmodul für die Daten-API, sodass wir einfach Regressionstests und Leistungstests schreiben können und wir versuchen immer mehr zu bauen.

Was macht Du, wenn Du nicht gerade programmierst?

Ich bin ein riesiger Baseball-Fan. Im Frühling bin ich Schiedsrichter bei College-Baseball, im Sommer bei verschiedenen Ligen und dann schaue und gehe ich zu Spielen der Chicago Cubs.

Englische Version

Meet the Team: Nick Coghlan

2011-07-14T13:53:00.000+02:00

Dieser Post ist Teil der "Meet the Team" Serie, die kurz das Python-Kernentwickler-Team vorstellen soll.

Name:	Nick Coghlan
Standort:	Brisbane, Australien
Homepage:	http://www.boredomandlaziness.org

Wie lange nutzt Du schon Python?

Mein erster Kontakt war etwa 1999 mit 1.5.2, als unser Dozent Python für einen Kurs über Netzwerke nutzte. Professionell startete ich etwa 2002 mit 2.2 für automatisierte Tests und habe es nie bereut.

Wie lange trägst Du schon zum Kern bei?

Guido gewährte mir Zugang in 2005, um PEP 343 (vor allem, um die context-Methode loszuwerden) zu aktualisieren.

Wie wurdest Du Kernentwickler? Erinnerst Du dich an deinen ersten Beitrag?

Was das Beitragen von Patches angeht, hatte ich 2004 drei Monate frei und verbrachte viel Zeit davon zusammen mit Raymond und Facundo mit der Arbeit am decimal-Modul, vor allem mit dem laufen lassen des telco-Benchmarks, um den Code schneller zu machen. Ein paar der seltsameren Hacks im decimal-Modul (wie die Abkürzung für das Überprüfen auf Sonderfälle und die Benutzung von Strings beim Umwandeln von Tupeln in Integer) stammen aus dieser Zeit.

Mein wirklich erster Commit war dann wohl zu PEP 343 und danach wahrscheinlich zum AST-Compiler-Zweig als wir ihn für die Aufnahme in 2.5 fertig machten.

An welchen Teilen von Python arbeitest Du jetzt?

runpy, functools und contextlib sind die Hauptsachen, die letztendlich in meinem Posteingang landen. Ich beobachte auch aufmerksam, was Brett und Victor mit import tun, was Raymond mit collections und itertools tut und alles was mit dem Compiler passiert. Auch fasziniert mich der kulturelle Aspekt der Dinge.

Was machst Du mit Python, wenn Du nicht gerade am Python-Kern schraubst?

Wirklich keine große Sache. Der Python-Kram auf der Arbeit leistet normalerweise einfach seine Arbeit, darum gibt es momentan keinen großen Bedarf daran zu arbeiten. Ich will etwas schaffen, das meine digitale Musiksammlung aufräumt, aber die Skripte, dafür sind momentan nur schnell zusammengeworfen.

Was macht Du, wenn Du nicht gerade programmierst?

Tae kwon do, Computerspiele, Fußball, Lesen, etc, etc...

Englische Version

Neues Blog Design

2011-07-10T20:14:00.001+02:00

Falls Du den Python Insider (oder die deutsche Übersetzung) über einen Feed-Reader liest, hast Du vielleicht das neue Design noch nicht bemerkt, das Marcin Wojtczuk für uns erstellt hat. Es sieht toll aus, erhält aber trotzdem ein leichtgewichtiges Lesegefühl und wir könnten nicht glücklicher mit den Ergebnissen sein.

Marcin: Danke für deine Zeit und Mühe!

Englische Version

urllib/urllib2 Sicherheitslücke behoben

2011-07-10T20:14:00.000+02:00

Guido van Rossum hat kürzlich einen Fix für CVE-2011-1521 gepusht, das ein Sicherheitsproblem in den URL-Bibliotheken von Python beschreibt. Obwohl Sicherheitslücken selten sind, ist dies eine gute Gelegenheit, um über den Prozess hinter dem Berichten, Behandeln und Beheben von Problemen zu informieren, wenn sie denn entstehen.

Problem berichten

Wenn Du eine Sicherheitslücke in CPython entdeckt hast, dann bitten wir Dich zuerst darum die Details vertraulich zu behandeln. Nachdem Du festgestellt hast, dass Du ein echtes Sicherheitsproblem gefunden hast, ist es am wichtigsten dein Wissen an die Kernentwickler weiterzugeben, indem Du einen prägnanten, aber detaillierten Bericht erstellst.

Ein guter Bericht erklärt, wie die relevanten Teile des Systems von dem Problem betroffen sind. Es ist auch hilfreich zu wissen, ob das Problem auf einer bestimmten Plattform oder wegen einer Abhängigkeit auftritt. Es ist nützlich die betroffenen Versionen zu wissen und es ist wahrscheinlich, dass alle aktuellen Releases auf die Schwachstelle hin überprüft werden. Zu guter Letzt: Wenn Du einen Testfall für das Problem hast, dann stelle sicher, dass Du ihn beifügst. Deinen Bericht solltest du an security@python.org schicken.

Niels Heinen vom Google Security Team hat kürzlich einen guten Bericht eingereicht. Er entdeckte ein Problem mit der HTTP 302-Umleitungsbehandlung in den urllib- und urllib2-Modulen der Standardbibliothek. Er fand heraus, dass ein Server Requests auf unpassende Schemata umleiten konnte und so Situationen erzeugten, die Systeme oder Daten kompromittieren könnten. In seinem ersten Bericht, erklärt Niels zwei Szenarien, in denen Weiterleitungen Probleme aufdecken könnten.

Da urlib/urllib2 einen Handler für das file:// URL-Schema anbietet, könnte eine Weiterleitung nach file:///etc/passwd Passwort-Daten preisgeben. Niels erklärte weiterhin, dass eine Weiterleitung auf ein Systemgerät wie file:///dev/zero zu Erschöpfung von Ressourcen und damit zu einem Denial of Service führen könnte.

Handhabung von Berichten

Aufgrund der sensiblen Natur von Sicherheitslücken, wird die security@python.org-Mailingliste von einer kleinen Gruppe vertrauenswürdiger Entwickler betreut, die Berichte analysieren und so schnell wie möglich auf sie reagieren. Wenn Du deine Kommunikation mit der Liste verschlüsseln willst, findest du auf der Security News-Seite die OpenPGP-Details.

Wenn die Gruppe feststellt, dass es wirklich eine Sicherheitslücke gibt, kann ein öffentlicher Fehlerbericht mit einem beigefügten Patch erstellt werden. In diesem Fall machte Guido van Rossum das Problem mit Issue #11662 öffentlich, inklusive erstem Patch.

Beheben des Problems

Guidos Patch schränkt die Weiterleitung auf die URL-Schemata http://, https:// und ftp:// ein. FTP-Weiterleitung wurde für akzeptabel befunden und es ist in der Tat eine häufige Weiterleitung: Spiegel-Server für Downloads leiten manchmal an geographisch passende FTP-Server weiter.

In Python 2.x verursacht die redirect_internal-Methode von FancyURLopener nun einen IOError, wenn eine Weiterleitung an ein ungeeignetes Schema angefragt wird, genauso wie http_error_302 von HTTPRedirectHandler, nur ist es hier ein HTTPError. In Python 3 wurde urllib.request entsprechend repariert. Zusammen mit dem Patch gibt es zwei Tests, die sowohl die Weiterleitung zu passenden wie zu unpassenden Schemata testen.

Was die Weiterleitung an Nutzer angeht, so wird bald das letzte Sicherheits-Release von Python 2.5 veröffentlicht. Obwohl noch keine Termine für die Wartungszweige -- 2.6, 2.7, 3.1 und 3.2 -- festgelegt sind, bekamen alle den Code um die Lücke zu schließen.

Englische Version

Meet the Team: Tarek Ziadé

2011-07-09T16:32:00.000+02:00

Dieser Post ist Teil der "Meet the Team" Serie, die kurz das Python-Kernentwickler-Team vorstellen soll.

Name:	Tarek Ziadé
Standort:	Turcey bei Dijon, Burgund, Frankreich
Homepage:	http://ziade.org

Wie lange nutzt Du schon Python?

Rund zehn Jahre.

Wie lange trägst Du schon zum Kern bei?

Seit dem 21. Dezember 2008.

Wie wurdest Du Kernentwickler? Erinnerst Du dich an deinen ersten Beitrag?

Ich wurde Kernentwickler, um Distutils zu warten und weiterzuentwickeln.

Mein erster Beitrag als Kernentwickler war ein Fix für einen kleinen Bug eines distutils-Feature, den ich vorgeschlagen habe bevor ich Committer wurde. Dieses Feature wurde in der vorigen Woche Python hinzugefügt. Es ist die Möglichkeit die register und upload Befehle von Distutils zu konfigurieren, damit sie mit anderen PyPI-artigen Servern zusammenarbeiten.

Ich committete mit meinen brandneuen Rechten am Mittwoch, den 24. Dezember 2008, der zufällig auch mein Geburtstag und der 17. Jahrestag des 0.9.4-Release von Python.

An welchen Teilen von Python arbeitest Du jetzt?

In der Standardbibliothek: sysconfig, distutils, packaging (kommt mit Python 3.3), shutil, pkgutil und gelegentlich an anderen Modulen.

Was machst Du mit Python, wenn Du nicht gerade am Python-Kern schraubst?

Ich arbeite bei Mozilla im Service Team, wo ich Web-Dienste mit Python baue.

Was macht Du, wenn Du nicht gerade programmierst?

Ich lese Comics/Graphic Novels, schreibe Bücher, spiele mit meinen Kindern, trinke Wein mit meiner Frau und versuche mein 1848-er Haus zu renovieren.

Englische Version

Formalisierung der AST-Change-Control-Policy

2011-07-02T13:18:00.001+02:00

Python legt mit dem AST-Modul einen abstrakten Syntaxbaum (abstract syntax tree -- AST) offen, der die kompilierte Form von Python-Quellcode darstellt. Das AST-Modul erlaubt Nutzern Code anhand der AST-Darstellung, zwischen Parsing des Quellcodes und der Kompilierung zu Bytecode, zu inspizieren und zu verändern.

Die Bedeutung von Python-Code ist in der Sprachreferenz definiert. Das AST-Modul ist ein CPython-Implementierungsdetail und andere Python-Implementierungen müssen es nicht implementieren.

Kompatibilität des AST

Als Teil der Arbeit CPythons Peephole-Optimierer umzuschreiben, sodass er auf dem AST arbeitet (anstatt auf dem rohen Bytecode, wie es momentan der Fall ist), musste Eugene Toder einige Änderungen an der Struktur des AST machen. Als CPython-Implementierungsdetail war es nicht sofort klar, ob die Richtlinie zur Rückwärtskompatibilität auch den AST betrifft. Also stellte Eugene die Frage auf python-dev. Ist es bei AST-Änderungen notwendig rückwärtskompatibel zu bleiben?

Der allgemeine Konsens war, dass Kompatibilität nicht nötig wäre. Das AST-Modul stellt eine Konstante, ast.__version__ bereit, die Nutzercode eine Möglichkeit bietet sein Verhalten der genutzten AST-Version anzupassen. Das wurde als ausreichend Kompatibilität für ein implementierungsspezifisches Modul angesehen.

Andere Python-Implementierungen

Tatsächlich haben sowohl Jython als auch IronPython darauf hingewiesen, dass ihre jeweiligen Implementierungen entweder ein kompatibles AST-Modul haben oder eines bereitstellen wollen. Trotzdem meinten sie nicht, dass deswegen der AST eingefroren werden sollte und sind damit glücklich, dass der AST inkompatibel geändert werden könnte, solange die ast.__version-Konstante geändert wird.

Es wurde auch angesprochen, dass eine vollständige Testsuite in test_ast.py anderen Implementierungen dabei helfen würden, sicherzustellen, dass ihre Implementierungen zu CPython kompatibel sind. Die Abdeckung von test_ast.py zu erhöhen würde sich gut als Projekt für jemanden eignen, der sich bei den Python-Interna engagieren will!

Was passiert als nächstes?

Der Patch, der die Diskussion lostrat, hat noch nicht in CPython Einzug gehalten. Also könnte möglicherweise gar nichts passieren. Aber, wenn es doch passiert, wird der AST sich inkompatibel ändern. Die ast.__version__-Konstante wird sich ändern, um das widerzuspiegeln und Nutzercode wird damit die Veränderungen bemerken, aber Änderungen werden nötig sein. Allgemeiner gesprochen wird dies die Art und Weise sein, wie AST-Änderungen in Zukunft gehandhabt werden.

Die Python-Entwickler sind interessiert zu erfahren, wie weit verbreitet die Nutzung des AST ist und wie viele Auswirkungen diese Handhabung haben wird. Wenn es Leser gibt, deren Code von der Änderung betroffen ist, so sind sie aufgefordert sich an der Diskussion auf python-dev zu beteiligen.

Englische Version

Thomas Heller tritt als ctypes-Maintainer zurück

2011-06-29T20:39:00.002+02:00

Das Python-Entwicklungs-Team schuldet dem ctypes-Maintainer Thomas Heller ein großes Dankeschön. Anfang des Monats verkündete Thomas sein Ausscheiden aus dem CPython-Projekt, das seit Python 2.5 die Heimat seiner ctypes-Bibliothek ist.

Ich hatte die Chance mit Thomas zu reden und er erzählte mir von seiner Geschichte mit Python und seinen Projekten ctypes und py2exe.

Python

Auf der Suche nach Ressourcen um Python zu lernen, fiel Thomas 1999 Mark Lutz' Programming Python in die Hände und er wurde direkt von der Sprache fasziniert. Er war gerade dabei Scheme als Erweiterungssprache für ein großes, für Windows geschriebenes, C-Programm zu ersetzen.

Sein erster Beitrag zu CPython (und Open Source im Allgemeinen) war ein kleiner Windows-bezogener Patch zu distutils. Sein Interesse an distutils brachte ihn schließlich zur Erstellung des bdist_wininst-Kommandos, das "point-and-click"-Windows-Installer erstellt. Danach wurde er von Greg Ward in die python-dev Gruppe eingeladen, wo er schließlich Commit-Rechte bekam.

py2exe

Wie viele Windows-Nutzer hatte er das Bedürfnis Python-Anwendungen als einzelne, ausführbare Datei weiterzugeben. Frühe Lösungsansätze für das Problem kamen von Fredrik Lundhs squeeze und Christian Tismers sqfreeze und Thomas hat mit mehreren Patches zu Gordon McMillans Installer-Projekt beigetragen.

Sein Interesse an distutils führte Thomas dazu Installer als eine Erweiterung der Bibliothek zu portieren. Jedoch endete es damit, dass er den Code umschrieb, um sicherzustellen, dass die existierenden Möglichkeiten von distutils genutzt werden. Am Ende wählte er den einfachen, aber beschreibenden Namen py2exe für das Projekt.

ctypes

Die Idee zu ctypes kam aus dem Bedürfnis nach mehr als was pywin32 seinerzeit bot. Zusätzlich benötigte er für seine Arbeit mit Scheme ein Interface zur Windows API, wie er es auch für seine Arbeit mit Python brauchte, also betrieb er sein Projekt weiter.

ctypes hatte sein erstes öffentliches Release in 2003, etwa zur Zeit des Python 2.3-Release, nachdem Thomas zahlreiche Anfragen bekam das Projekt zu veröffentlichen. Er erwähnte sein ehemals kleines, privates Projekt auf seiner Starship-Seite, aber in kurzer Zeit wurde es zu einer weit verbreiteten Bibliothek.

Ursprünglich startete er das Projekt unter Windows, aber schnell wurde der Ruf nach einer Linux-Portierung laut, die er mit Hilfe der Community umsetzte. Mit der Linux-Portierung wurde libffi im Projekt eingeführt, das er auch unter Windows zu benutzen begann, um die zugrundeliegende Implementierung auszutauschen.

2006 markierte ein 1.0-Release für ctypes, das sich mit der Aufnahme in die Standardbibliothek von Python 2.5 deckte. Nach Jahren harter Arbeit und vielen Veröffentlichungen pro Jahr, war ctypes nun mit Python gebündelt und standardmäßig für eine viel breitere Zielgruppe zugänglich.

Es waren viele Leute nötig, um ctypes dorthin zu bringen, wo es heute ist, und Thomas will jedem danken, der mitgewirkt hat, aber vor allem Robin Becker. Robin war in den frühen Phasen des Projekts beteiligt und steuerte sowohl Wissen, als auch Unterstützung bei.

Ein neuer ctypes-Maintainer

Nach all der harten Arbeit, die Thomas über die Jahre investiert hat, würde er ungern sehen, dass das Projekt zum Stillstand kommt. Wenn Du Erfahrung mit C und Zeit dem Python-Projekt zu helfen, würde die Python-Community Deine Dienste sehr schätzen. Mehr Informationen gibt es im neuen Developer Guide und im Bug Tracker.

Englische Version

Meet the Team: Benjamin Peterson

2011-06-25T12:53:00.000+02:00

Dieser Post ist Teil der "Meet the Team" Serie, die kurz das Python-Kernentwickler-Team vorstellen soll.

Name:	Benjamin Peterson
Standort:	Minnesota, USA
Homepage:	http://benjamin-peterson.org
Blog:	http://pybites.blogspot.com

Wie lange nutzt du schon Python?

3 1/2 Jahre.

Wie lange trägst du schon zum Kern bei?

Diesen 25. März genau drei Jahre.

Wie wurdest du Kernentwickler? Erinnerst du dich an deinen ersten Beitrag?

Mein erster Vorschlag wurde von Guido selbst zurückgewiesen. Zum Glück blieb ich hartnäckig und es wurden ein paar Patches akzeptiert. Ich glaube mein erster Beitrag war eine Neuordnung der Misc/ACKS-Datei.

An welchen Teilen von Python arbeitest du jetzt?

Ich mag den Parser-, Compiler- und Interpreter-Kern, aber ich bin bekannt dafür in fast jedem Teil der Python-Kernentwicklung herumzupfuschen... außer Windows!

Was machst du mit Python wenn du nicht gerade am Python-Kern schraubst?

Ich benutze es um einen Python-Interpreter zu bauen (http://pypy.org)! Ich bin im Innersten wirklich ein Python-Implementierer. :) Ich bin der Schöpfer von six, einer Python 2 und 3 Kompatibilitätsbibliothek.

Was macht du wenn du nicht gerade programmierst?

Musik komponieren, Klarinette spielen und Mathebücher lesen. Hin und wieder wandere ich auch ein bisschen.

Englische Version

Deprecations zwischen Python 2.7 und 3.x

2011-06-23T14:24:00.001+02:00

Eine kürzliche Diskussion auf python-dev zeigte ein Problem mit Pythons momentaner Verfahrensweise bezüglich Deprecations auf, das Entwickler betrifft, die von Python 2.7 auf aktuelle Versionen von Python 3.x umsteigen. Aufgrund dieses Problems hat das Entwickler-Team die aktuelle Deprecation-Policy angepasst, um die Tatsache zu berücksichtigen, dass Python-Nutzer normalerweise direkt von Python 2.7 auf die letzte Version von 3.x umsteigen, ohne je ältere Versionen gesehen zu haben.

Hintergrund

Python hat ein starkes Bekenntnis zur Rückwärtskompatibilität. Keine Veränderung ist erlaubt, ohne dass sie den Kompatibilitätsrichtlinien entspricht, was im Grunde heißt, dass korrekte Programme auch unter neuen Python-Versionen korrekt laufen. Aber das ist nicht immer möglich, beispielsweise wenn eine API klar kaputt ist und durch etwas anderes ersetzt werden muss. In dem Fall verfolgt Python eine Deprecation-Policy, die besagt, dass zu entfernende Features in einem einjährigen Übergangszeitraum formell deprecated werden. In diesem Übergangszeitraum muss eine DeprecationWarning ausgegeben werden, um den Entwicklern Zeit zu geben ihren Code zu aktualisieren. PEP 5 beschreibt die vollen Details von Pythons Deprecation-Policy. Da Veränderungen nur in neuen Python-Releases gemacht werden und es normalerweise eine 18-monatige Lücke zwischen Releases gibt, bedeutet das, dass dieser Zeitraum normalerweise einem Release entspricht.

Die eine Ausnahme zu dieser Verfahrensweise war Python 3. Der große Versionssprung zwischen Python 2 und Python 3 war genau dazu gedacht Veränderungen zu machen, die die Rückwärtskompatibilität brechen, um den Python-Entwicklern die Möglichkeit zu geben Probleme zu beheben, die einfach nicht innerhalb der Verfahrensweise behoben werden konnten. Zum Beispiel Strings standardmäßig zu Unicode zu machen und Iteratoren statt Listen zurückzugeben.

Parallele Entwicklungszweige

Wohlwissend, dass der Übergang nach Python 3 Zeit brauchen würde, nach vielen Schätzungen 5 Jahre, gab es in einigem Umfang eine parallele Entwicklung von Python 2 und 3.

Da Python 2.7 der letzte Release von Python 2 sein wird, wurde vereinbart, dass hier der Wartungszeitraum erheblich ausgedehnt wird. Letztlich müssen Entwickler, die zu einer neueren Version von Python wechseln wollen, also den Sprung nach Python 3 machen.

Und genau hier liegt das Problem ...

Überraschungsdeprecations

In einem Thread auf python-dev, wurde darauf hingewiesen, dass eine spezifische Funktion der C-API, PyCObject_AsVoidPtr, entfernt wurde, ohne dass davor ausreichend gewarnt wurde. Und doch soll die Deprecation-Policy genau das verhindern! Was ist also passiert?

Die Änderung war Teil einer größeren Migration von einer älteren API (PyCObject) zu einer neueren und verbesserten API (PyCapsule). Das Problem ist, dass PyCObject die Standard-API war und sogar die einzige in Python 2.6 verfügbare. Das API wurde in Python 2.7 deprecated. In Python 3.2 gibt es sie nicht und PyCapsule sollte genutzt werden. Damit gibt es einen Übergangszeitraum vom Release von Python 2.7 (Juli 2010) bis zum Release von Python 3.2 (Februar 2011), also knapp 7 Monate. Das ist erheblich weniger als der 12-Monate-Mindestzeitraum und macht es Entwicklern schwer eine sinnvolle Auswahl von Python-Releases zu unterstützen.

Für jemandem, der von 3.0 zu 3.1 und danach zu 3.2 wechselt, ist der Übergang in Ordnung. Python 3.1 wurde im März 2010 mit der Deprecation veröffentlicht und so gab es in der Python 3.x-Serie einen Übergangszeitraum von fast 12 Monaten. Allerdings ist das nicht, was Entwickler normalerweise tun: Sie gehen von Python 2.7 direkt zur letzten Version von Python 3.x, in diesem Fall Python 3.2, und schaffen so das Problem. Dies war nie die Absicht von python-dev, aber beim Schreiben von PEP 5 wurde nicht an zwei parallele Versionen gedacht, die beide aktiv entwickelt wurden.

Was machen wir also?

Auch wenn der PyCObject/PyCapsule-API-Bruch ein echtes Problem ist, so ist es nicht unmöglich es zu umgehen, aber mindestens ein Poster hatte auf python-dev Schwierigkeiten damit. Insgesamt hätte das nie passieren dürfen.

Für den speziellen Fall von PyCObject/PyCapsule gibt es das Problem schon und es kann nicht viel dagegen getan werden. PyCObject wieder einzusetzen stand nicht wirklich zur Debatte, da es nur noch mehr Inkompatibilitäten schaffen würde. Jedoch war die allgemeine Ansicht, dass es möglich, wenn auch mühsam, wäre Code zu schreiben, der sich jeder verfügbaren API anpassen könnte. In der Tat war in Python 3.1 die PyCObject-API nur eine Schicht auf der PyCapsule-API. Es gab auch den Vorschlag, dass man falls nötig die Python 3.1 Implementierung extrahieren und als Dritt-Modul anbieten könnte. Man war sich einig, dass man ein "rückwirkendes" PEP schreiben würde, um die Gründe hinter der Veränderung zu beschreiben und Ressourcen zu dokumentieren, die Entwicklern beim Umstieg helfen können.

Allgemein gesprochen ist das Python-Entwicklungsteam nun mit dem Problem vertraut und wird daran arbeiten, dass es nicht wieder passieren wird. Guido veröffentlichte eine Überprüfung der Situation und schlug vor, dass man für den Moment in Python 3 sparsam mit Deprecations umgehen sollte. Mindestens sollten deprecated APIs erheblich länger behalten werden, bevor sie entfernt werden, um von Python 2.7 kommenden Entwicklern einen Migrationspfad zu bieten.

Indirekter wurde in dem Thread auch das Problem behandelt wie man effektiver Veränderungen in Python zeitnaher und einem breiterem Kreis kommunizieren könnte -- genau die Art von Problem also, für die dieses Blog geschaffen wurde.

Was bedeutet das alles?

In erster Linie bedeutet das, dass die Python-Entwickler nicht immer alles richtig machen. Niemand wollte den Entwicklern das Leben schwer machen, sondern es war einfach ein Problem, das nicht rechtzeitig entdeckt wurde.

Zweitens, dass das Beheben des Problems mehr Schaden als Nutzen kann, weshalb das PyCObject-API nicht wieder eingesetzt wurde. Zwar würde das Entwicklern helfen, die von der Veränderung gebissen wurden, aber zu dem Preis, dass Kompatibilitätsprobleme komplexer würden. In der Zwischenzeit müssen wir mit dem Problem leben und weiter machen. Lehren wurden daraus gezogen und wir werden den Fehler nicht nochmal machen.

Dies zeigt auch, dass das Python-Entwicklerteam von seinen Anwendern hören will. Kompatibilität ist wichtig und es wird alles daran gesetzt den Übergang zu neuen Versionen so schmerzlos wie möglich zu machen. Besonders Bibliotheken-Entwickler sollten mit einem angemessenen Maß an Aufwand mehrere Python-Versionen unterstützen können.

Schließlich heißt das: Entwickler haben Python 2.7 noch nicht verlassen. Obwohl es keine neue Features und kein Python 2.8 geben wird, sind die Ansichten der Python 2.7-Nutzer dennoch wichtig. Es ist wesentlich für die gesamte Python-Community, sicherzustellen, dass Nutzer zu 3.x wechseln können, wenn sie bereit sind.

Englische Version

Von Polling, futures und Paralleler Ausführung

2011-06-04T15:43:00.002+02:00

Eines der großen Problemfelder im modernen Computerwesen ist Stromsparen. Es hat besonders Gewicht in tragbaren Geräten (Laptops, Tablets, Handhelds). Eine moderne CPU ist in der Lage in viele stromsparende Modi zu wechseln, wenn sie nichts zu tun hat. Je länger sie untätig ist, desto tiefer der stromsparende Modus und desto weniger Energie wird verbraucht und damit hält der Akku eines Geräts umso länger mit einer einfachen Aufladung.

Stromspar-Modi haben einen Feind: Polling. Weckt ein Prozess die CPU periodisch auf, auch für so etwas triviales wie das Lesen einer Speicherstelle, um eventuelle Änderungen zu erkennen, verlässt die CPU den Stromspar-Modus, weckt alle seine internen Strukturen und wird erst wieder in den Stromspar-Modus wechseln, wenn der kleine periodischer Prozess seine beabsichtigte Arbeit schon lange beendet hat. Intel selbst ist besorgt.

Python 3.2 kommt mit einem neuen Standardmodul, um nebenläufige Arbeiten anzustoßen und auf ihre Beendigung zu warten: concurrent.futures. Während ich den Code durchsah, bemerkte ich, dass es in manchen seiner Arbeitsthreads und -prozesse Polling nutzte. "Manche", weil sich die Implementierung von ThreadPoolExecutor und von ProcessPoolExecutor unterscheidet. Erste pollt in jedem seiner Arbeitsthreads, während die Zweite es nur in einem einzigen Thread, dem "queue management thread", tut, der zur Kommunikation zwischen den Arbeitsprozessen genutzt wird.

Polling wurde hier nur für eine Sache genutzt: Um zu erkennen, wann die Abschaltprozedur ausgeführt werden soll. Für andere Aufgaben, wie das Einreihen von Callables oder das Holen von Ergebnissen, vorher eingereihter Callables, werden synchronisierte Queue-Objekte benutzt. Diese Queue-Objekte kommen entweder aus dem threading- oder dem multiprocessing-Modul, je nachdem welche Executor-Implementierung genutzt wird.

Also entwickelte ich eine einfache Lösung: Ich ersetzte das Polling mit einem Sentinel, dem eingebauten Sentinel None. Bekommt eine Queue ein None, dann wacht ein wartender Arbeiter natürlicherweise auf und überprüft, ob er sich Abschalten sollte oder nicht. Im ProcessPoolExecutor gibt es eine kleine Komplikation, da man neben dem einen "queue managing thread" N Arbeitsprozesse aufwecken muss.

Im ersten Patch gab es immernoch einen Polling-Timeout, wenn auch einen sehr großen (10 Minuten), sodass die Arbeiter an irgendeinem Zeitpunkt aufwachen würden. Der große Timeout existierte, für den Fall, dass der Code fehlerhaft ist und keine Benachrichtigung zum Abschalten durch den schon genannten Sentinel verteilt würde. Aus Neugier tauchte ich in den multiprocessing-Code und machte eine weitere interessante Entdeckung: Unter Windows benutzt multiprocessing.Queue.get() , mit einem von Null verschiedenen, nicht-unendlichen Timeout, ... Polling (weshalb ich Issue 11668 öffnete). Es benutzt eine interessante hochfrequente Art des Pollings, da es mit einem Millisekunden Timeout beginnt, der mit jedem Durchgang erhöht wird.

Natürlich macht die Benutzung eines Timeouts, egal wie groß, meinen Patch unter Windows zwecklos, da die Art der Implementierung ein Aufwachen jede Millisekunde bedeutet. Also hab ich die bittere Pille geschluckt und den riesigen Timeout entfernt. Der letzte Patch kommt komplett ohne Timeout aus und sollte damit, egal auf welcher Plattform, kein periodisches Aufwachen verursachen.

Historisch gesprochen, nutzte vor Python 3.2 jede Timeout-Einrichtung des threading-Moduls - und damit ein Großteil von multiprocessing, da multiprocessing selbst Arbeitsthreads für verschiedene Aufgaben nutzt - Polling. Dies wurde mit Issue 7316 behoben.

Englische Version

2011 Language Summit Report

2011-05-19T14:51:00.001+02:00

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.

Englische Version

Willkommen zum Python Insider!

2011-05-11T09:45:00.001+02:00

Der Python Insider ist das offizielle Blog der Python Kern-Entwickler. Es will auch denen, die die Mailinglisten nicht lesen, einen Überblick über die dort besprochenen Themen geben und vor allem über anstehende Änderungen in Python informieren. Wir werden über Tätigkeiten rund um python-dev schreiben, wie die vor kurzem vollendete Migration zu einem Mercurial-basiertem Hosting, neu akzeptierte Python Enhancement Proposals (PEPs -- Vorschläge zur Python-Weiterentwicklung), API-Änderungen und andere größere Anstrengungen in der Python Kern-Entwicklung.

Dieses Blog ist eine Ergänzung -- und kein Ersatz -- zur python-dev Mailingliste und zu individuellen Entwickler-Blogs [1]. Es wird ein Kanal sein, auf dem öffentlich über Projekte geredet wird, die schon fertig sind oder ein Stadium erreichen, in dem mehr Freiwillige nötig werden. Zwar werden Diskussionen auf dem Blog begrüßt [2], aber wir hoffen, dass Leute, die sich für die Themen interessieren der python-dev Mailingliste beitreten und dort die Diskussion und Entwicklung direkt verfolgen.

Dieses Blog ist dein Fenster in die Entwicklung von Python.

Hilfe gesucht

Obwohl wir ein Team von dedizierten Schreibern haben, die an Posts für das Blog arbeiten, suchen wir jemanden mit Web Design Kenntnissen, der am Blogger Template arbeiten würde. Wenn Du uns helfen kannst dem Blog ein Facelifting zu verpassen, melde dich bei Doug Hellmann (doug dot hellmann at gmail -- englischsprachig)

Englische Version

[1]	siehe auch die Links in der Seitenleiste

[2]	Alle Python-Entwickler sprechen englisch, darum ist die angesprochene Diskussion im englischen Blog am besten aufgehoben.