Vorwort zu "Programming Python" (2. Auflage)

Vor weniger als fünf Jahren schrieb ich das Vorwort zur 1. Auflage von Programming Python. Seitdem hat sich das Buch etwa so stark verändert wie die Sprache und die Python-Community! Ich sehe nicht mehr die Notwendigkeit, Python zu verteidigen: Die Statistiken und Entwicklungen, die in Mark's Vorrede aufgeführt sind, sprechen für sich.

Im vergangenen Jahr hat Python große Fortschritte gemacht. Wir haben Python 2.0 veröffentlicht, einen großen Schritt nach vorn, mit neuen Standardbibliotheksfunktionen wie Unicode- und XML-Unterstützung sowie mehreren neuen syntaktischen Konstrukten, darunter die erweiterte Zuweisung: Sie können jetzt x += 1 statt x = x+1 schreiben. Einige Leute fragten sich, was das Besondere daran sei (Antwort: stellen Sie sich anstelle von x dict[key] oder list[index] vor), aber insgesamt war dies ein großer Erfolg bei den Benutzern, die bereits an die erweiterte Zuweisung in anderen Sprachen gewöhnt waren.

Weniger herzlich war die Begrüßung für die erweiterte Print-Anweisung: print>>file, eine Abkürzung für das Drucken in ein anderes Dateiobjekt als die Standardausgabe. Persönlich ist es die Python 2.0-Funktion, die ich am häufigsten verwende, aber die meisten Leute, die sich dazu geäußert haben, fanden sie eine Abscheulichkeit. Der Diskussionsfaden in der Newsgruppe, der diese einfache Spracherweiterung verriss, war einer der längsten überhaupt – abgesehen vom nie endenden Thread Python vs. Perl.

Was mich zum nächsten Thema bringt. (Nein, nicht Python vs. Perl. Es gibt bessere Orte, um Streitigkeiten auszutragen, als ein Vorwort.) Ich meine die Geschwindigkeit der Python-Entwicklung, ein Thema, das dem Autor dieses Buches am Herzen liegt. Jedes Mal, wenn ich eine Funktion zu Python hinzufüge, wird ein weiterer Fleck von Mark's Haar grau: Da ist schon wieder ein Kapitel veraltet! Besonders die Flut neuer Funktionen, die zu Python 2.0 hinzugefügt wurden und gerade erschienen, als er an dieser zweiten Auflage arbeitete, ließen ihn befürchten: Was, wenn Python 2.1 genauso viele neue Dinge hinzufügt? Das Buch wäre veraltet, sobald es veröffentlicht wird!

Entspann dich, Mark. Python wird sich weiterentwickeln, aber ich verspreche, dass ich keine Dinge entfernen werde, die aktiv genutzt werden! Zum Beispiel gab es viele Sorgen wegen des string-Moduls. Jetzt, wo String-Objekte Methoden haben, ist das string-Modul größtenteils überflüssig. Ich wünschte, ich könnte es für obsolet (oder veraltet) erklären, um Python-Programmierer zu ermutigen, stattdessen String-Methoden zu verwenden. Aber da die große Mehrheit des vorhandenen Python-Codes – sogar viele Standardbibliotheksmodule – das string-Modul importiert, wird diese Änderung offensichtlich nicht über Nacht geschehen. Die erste wahrscheinliche Gelegenheit, das string-Modul zu entfernen, wird bei der Einführung von Python 3000 sein; und selbst dann wird es wahrscheinlich ein string-Modul in der Abwärtskompatibilitätsbibliothek für die Verwendung mit altem Code geben.

Python 3000?! Ja, das ist der Spitzname für die nächste Generation des Python-Interpreters. Der Name kann als Wortspiel mit Windows 2000 verstanden werden oder als Anspielung auf Mystery Science Theatre 3000, eine passend Pythoneske Fernsehsendung mit Kultstatus. Wann wird Python 3000 veröffentlicht? Nicht mehr lange – obwohl Sie nicht ganz bis zum Jahr 3000 warten müssen.

Ursprünglich war Python 3000 als vollständige Neufassung und Neugestaltung der Sprache gedacht. Es hätte mir erlaubt, inkompatible Änderungen vorzunehmen, um Probleme im Sprachdesign zu beheben, die auf rückwärtskompatible Weise nicht gelöst werden konnten. Der aktuelle Plan ist jedoch, dass die notwendigen Änderungen schrittweise in die aktuelle Entwicklungslinie von Python 2.x eingeführt werden, mit einem klaren Übergangspfad, der eine Phase der Abwärtskompatibilität einschließt.

Nehmen wir zum Beispiel die Ganzzahldivision. In Anlehnung an C definiert Python derzeit x/y mit zwei Ganzzahlargumenten als Ganzzahlergebnis. Mit anderen Worten, 1/2 ergibt 0! Während die meisten eingefleischten Programmierer dies erwarten, ist es eine ständige Quelle der Verwirrung für Neulinge, die einen immer größeren Teil der – exponentiell wachsenden – Python-Benutzerpopulation ausmachen. Aus numerischer Sicht ist es sinnvoller, dass der / Operator unabhängig vom Typ der Operanden denselben Wert ergibt: schließlich tun das alle anderen numerischen Operatoren. Aber wir können Python nicht einfach so ändern, dass 1/2 0,5 ergibt, denn (wie das Entfernen des string-Moduls) würde dies zu viel bestehenden Code brechen. Was tun?

Die Lösung, zu komplex, um sie hier im Detail zu beschreiben, wird mehrere Python-Releases umfassen und eine schrittweise Erhöhung des Drucks auf Python-Programmierer (zuerst durch Dokumentation, dann durch Verwarnungen und schließlich durch Fehler) beinhalten, ihren Code zu ändern. Übrigens wird ein Framework zur Ausgabe von Warnungen als Teil von Python 2.1 eingeführt. Tut mir leid, Mark!

Erwarten Sie also nicht, dass die Ankündigung der Veröffentlichung von Python 3000 bald erfolgen wird. Stattdessen werden Sie eines Tages feststellen, dass Sie Python 3000 bereits verwenden – nur wird es nicht so heißen, sondern eher etwas wie Python 2.8.7. Und das meiste, was Sie in diesem Buch gelernt haben, wird immer noch gelten! Dennoch werden in der Zwischenzeit Verweise auf Python 3000 allgegenwärtig sein; wissen Sie einfach, dass dies absichtlich Vaporware im reinsten Sinne des Wortes ist. Anstatt sich Gedanken über Python 3000 zu machen, verwenden Sie weiterhin die Python-Version, die Sie haben, und lernen Sie mehr darüber.

Ich möchte ein paar Worte über das aktuelle Entwicklungsmodell von Python sagen. Bis Anfang 2000 gab es Hunderte von Beitragenden zu Python, aber im Wesentlichen mussten alle Beiträge über meine Inbox laufen. Um eine Änderung an Python vorzuschlagen, würden Sie mir einen Kontext-Diff schicken, den ich auf meine Arbeitsversion von Python anwenden würde, und wenn er mir gefiel, würde ich ihn in meinen CVS-Quellbaum einchecken. (CVS ist ein Quellcode-Versionsverwaltungssystem und Thema mehrerer Bücher.) Fehlerberichte folgten demselben Weg, außer dass ich auch den Patch erstellen musste. Angesichts der steigenden Anzahl von Beiträgen wurde meine Inbox eindeutig zu einem Engpass. Was tun?

Glücklicherweise war Python nicht das einzige Open-Source-Projekt mit diesem Problem, und ein paar schlaue Leute bei VA Linux kamen auf eine Lösung: SourceForge! Dies ist eine dynamische Website mit einer vollständigen Palette von verteilten Projektmanagement-Tools: ein öffentliches CVS-Repository, Mailinglisten (mit Mailman, einer sehr beliebten Python-Anwendung!), Diskussionsforen, Fehler- und Patch-Manager sowie ein Download-Bereich, die alle auf Anfrage jedem Open-Source-Projekt zur Verfügung gestellt werden.

Wir haben derzeit eine Entwicklungsgruppe mit 30 Freiwilligen mit SourceForge-Checkin-Rechten und eine Entwicklungs-Mailingliste, die doppelt so viele Leute umfasst. Die privilegierten Freiwilligen haben alle ihre Treue zum BDFL (Benevolent Dictator For Life – das bin ich :-) geschworen. Die Einführung wichtiger neuer Funktionen wird über ein leichtgewichtiges System von Vorschlägen und Feedback, Python Enhancement Proposals (PEPs), geregelt. Unser PEP-System war so erfolgreich, dass es von der Tcl-Community fast eins zu eins kopiert wurde, als sie einen ähnlichen Übergang von Kathedrale zu Basar vollzogen.

Mit Zuversicht in die Zukunft von Python übergebe ich also das Wort an Mark Lutz. Ausgezeichnete Arbeit, Mark. Und um mit meinem Lieblingszitat von Monty Python abzuschließen: Übernehmen Sie, Eric, der Orchesterleiter!

Guido van Rossum
Reston, Virginia, Januar 2001