Sonntag, 9. Oktober 2011

Meet the Team: Brett Cannon

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

Sonntag, 21. August 2011

Meet the Team: Michael Foord

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.

Mittwoch, 17. August 2011

Ein Python-Starter für Windows

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:

Englische Version

Freitag, 12. August 2011

CPython 3.2.1 Released

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

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

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.

Samstag, 6. August 2011

Neues faulthandler Modul in Python 3.3 hilft bei der Fehlersuche

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