Vorwort zu "Programming Python" (1. Auflage)

Als Schöpfer von Python möchte ich ein paar Worte über seine Ursprünge sagen und dabei ein wenig persönliche Philosophie einfließen lassen.

Vor über sechs Jahren, im Dezember 1989, suchte ich nach einem "Hobby"-Programmierprojekt, das mich während der Weihnachtswoche beschäftigen würde. Mein Büro (ein staatliches Forschungslabor in Amsterdam) war geschlossen, aber ich hatte einen Heimcomputer und sonst nicht viel zu tun. Ich beschloss, einen Interpreter für die neue Skriptsprache zu schreiben, über die ich in letzter Zeit nachgedacht hatte: ein Nachfahre von ABC, der Unix/C-Hacker ansprechen sollte. Ich wählte Python als Arbeitstitel für das Projekt, da ich in einer leicht respektlosen Stimmung war (und ein großer Fan von Monty Python's Flying Circus bin).

Heute kann ich mit Sicherheit sagen, dass Python mein Leben verändert hat. Ich bin auf einen anderen Kontinent gezogen. Ich verbringe meine Arbeitstage mit der Entwicklung großer Systeme in Python, wenn ich nicht gerade an Python bastle oder Python-bezogene E-Mails beantworte. Es gibt Python-T-Shirts, Workshops, Mailinglisten, eine Newsgruppe und jetzt ein Buch. Ehrlich gesagt, mein einziger unerfüllter Wunsch ist es, mein Bild auf der Titelseite der New York Times zu sehen. Aber bevor ich mich in Tagträumen verliere, hier ein paar Anekdoten aus Pythons Vergangenheit.

Alles begann mit ABC, einer wunderbaren Lehrsprache, zu deren Erstellung ich in den frühen Achtzigern beigetragen hatte. Es war eine unglaublich elegante und leistungsfähige Sprache, die sich an Nicht-Programmierer richtete. Trotz all ihrer Eleganz und Leistungsfähigkeit und der Verfügbarkeit einer kostenlosen Implementierung wurde ABC in der Unix/C-Welt nie populär. Ich kann nur über die Gründe spekulieren, aber hier ist einer: die Schwierigkeit, neue "primitive" Operationen zu ABC hinzuzufügen. Es war ein monolithisches, "geschlossenes System" mit nur den grundlegendsten I/O-Operationen: eine Zeichenkette von der Konsole lesen, eine Zeichenkette auf die Konsole schreiben. Ich beschloss, diesen Fehler in Python nicht zu wiederholen.

Neben dieser Absicht hatte ich eine Reihe weiterer Ideen zur Verbesserung von ABC und war begierig darauf, sie auszuprobieren. Zum Beispiel erwiesen sich ABCs leistungsstarke Datentypen als weniger effizient als erhofft. Es wurde zu viel Wert auf theoretisch optimale Algorithmen gelegt und zu wenig auf die Optimierung für häufige Fälle. Ich hatte auch das Gefühl, dass einige von ABCs Funktionen, die sich an Anfänger richteten, für die (damals!) angedachte Zielgruppe erfahrener Unix/C-Programmierer weniger wünschenswert waren. Zum Beispiel: ABCs eigenwillige Syntax (Schlüsselwörter in Großbuchstaben!); einige Terminologie (z. B. "how-to" anstelle von "prozedur"); und der integrierte strukturierte Editor, den seine Benutzer fast universell hassten. Python sollte sich stärker auf die Unix-Infrastruktur und Konventionen stützen, ohne an Unix gebunden zu sein. Und tatsächlich wurde die erste Implementierung auf einem Mac vorgenommen.

Wie sich herausstellte, ist Python bemerkenswert frei von vielen der Nachteile herkömmlicher Programmiersprachen. Dies liegt vielleicht an meiner Wahl der Beispiele: Neben ABC war mein Hauptzeuge Modula-3. Dies ist eine weitere Sprache von bemerkenswerter Eleganz und Leistungsfähigkeit, die von einem kleinen, willensstarken Team entworfen wurde (von denen ich die meisten während eines Sommerpraktikums im Systems Research Center von DEC in Palo Alto kennengelernt hatte). Stellen Sie sich vor, wie Python ausgesehen hätte, wenn ich es nach der Unix-Shell und C modelliert hätte! (Ja, ich habe auch von C geliehen, aber nur seine am wenigsten kontroversen Merkmale, in meinem Bestreben, das Unix/C-Publikum zufriedenzustellen.)

Jede individuelle Schöpfung hat ihre Eigenheiten, und manchmal muss der Schöpfer diese rechtfertigen. Vielleicht ist Pythons umstrittenstes Merkmal die Verwendung von Einrückungen zur Gruppierung von Anweisungen, die direkt von ABC stammt. Es ist eine der Eigenschaften der Sprache, die mir am Herzen liegt. Sie macht Python-Code auf zwei Arten lesbarer. Erstens reduziert die Verwendung von Einrückungen die visuelle Unübersichtlichkeit und macht Programme kürzer, wodurch die Aufmerksamkeitsspanne, die zum Erfassen einer Basiseinheit von Code benötigt wird, reduziert wird. Zweitens lässt sie dem Programmierer weniger Freiheit bei der Formatierung und ermöglicht so einen einheitlicheren Stil, der das Lesen des Codes anderer erleichtert. (Vergleichen Sie beispielsweise die drei oder vier verschiedenen Konventionen für die Platzierung von geschweiften Klammern in C, jede mit starken Befürwortern.)

Dieser Fokus auf Lesbarkeit ist kein Zufall. Als objektorientierte Sprache zielt Python darauf ab, die Erstellung wiederverwendbaren Codes zu fördern. Selbst wenn wir alle jederzeit perfekte Dokumentationen schreiben würden, kann Code kaum als wiederverwendbar betrachtet werden, wenn er nicht lesbar ist. Viele der Funktionen von Python tragen, zusätzlich zur Verwendung von Einrückungen, dazu bei, Python-Code äußerst lesbar zu machen. Dies spiegelt die Philosophie von ABC wider, die darauf abzielte, Programmieren in seiner reinsten Form zu lehren und legte daher großen Wert auf Klarheit.

Lesbarkeit wird oft durch die Reduzierung unnötiger Variabilität verbessert. Wenn möglich, gibt es einen einzigen, offensichtlichen Weg, ein bestimmtes Konstrukt zu codieren. Dies reduziert die Anzahl der Entscheidungen, vor denen der programmierende Leser steht, und erhöht die Wahrscheinlichkeit, dass es für einen zweiten Leser vertraut erscheint. Ein weiterer Beitrag zur Lesbarkeit von Python ist die Entscheidung, Satzzeichen hauptsächlich auf konservative, konventionelle Weise zu verwenden. Die meisten Operatorsymbole sind jedem vertraut, der sich auch nur vage an die Highschool-Mathematik erinnert, und für Comic-Fluchzeichen wie @&$!. müssen keine neuen Bedeutungen gelernt werden.

Ich gebe gerne zu, dass Python nicht die schnellste Skriptsprache ist. Es ist jedoch ein guter Zweiter. Bei der ständig steigenden Hardwaregeschwindigkeit ist die kumulierte Laufzeit eines Programms während seiner Lebensdauer oft vernachlässigbar im Vergleich zur Programmiererzeit, die zum Schreiben und Debuggen benötigt wird. Hier können natürlich die wirklichen Einsparungen erzielt werden. Obwohl dies schwer objektiv zu bewerten ist, wird Python von den meisten, die es ausprobiert haben, als Gewinner in Bezug auf die Codierungszeit angesehen. Außerdem halten viele die Verwendung von Python für ein Vergnügen - eine bessere Empfehlung ist schwer vorstellbar.

Ich bin allein verantwortlich für Pythons Stärken und Schwächen, auch wenn ein Teil des Codes von anderen geschrieben wurde. Sein Erfolg ist jedoch das Produkt einer Gemeinschaft, beginnend mit den frühen Anwendern, die es aufnahmen, als ich Python zum ersten Mal im Netz veröffentlichte, und die die Nachricht in ihrer eigenen Umgebung verbreiteten. Sie schickten mir ihr Lob, ihre Kritik, Funktionswünsche, Codebeiträge und persönliche Offenbarungen per E-Mail. Sie waren bereit, jeden Aspekt von Python in der von mir bald eingerichteten Mailingliste zu diskutieren und mich zu schulen oder in die richtige Richtung zu stoßen, wo meine anfängliche Intuition versagte. Es gab zu viele Mitwirkende, um sie einzeln zu danken. Eine Ausnahme mache ich jedoch: Der Autor dieses Buches war einer der frühen Anwender und Evangelisten von Python. Mit seiner Veröffentlichung erfüllt sich sein lang gehegter Wunsch (und meiner!) nach einer zugänglicheren Beschreibung von Python als der Standardreihe von Handbüchern.

Aber genug der Ausschweifungen. Ich empfehle dieses Buch jedem, der daran interessiert ist, Python zu lernen, sei es zur persönlichen Weiterbildung oder zur Karriereförderung. Übernehmen Sie das Wort, Eric, der Orchesterleiter! (Wenn Sie den letzten Satz nicht verstehen, haben Sie nicht genug Monty-Python-Wiederholungen gesehen.)

Guido van Rossum
Reston, VA, Mai 1996