Download und weitere Informationen finden sich auf http://www.python.org

Hier ist eine kleine Sammlung von PythonResourcen. Ausserdem gibt es eine Seite mit PythonIdioms.

Eng verwandt mit Python ist Jython (Python in Java und umgekehrt). Siehe SpracheJython.

Wie durch eine empirische Untersuchung ( http://wwwipd.ira.uka.de/~prechelt/Biblio/#jccpprtTR) belegt ist, ist Python eine der produktivsten ProgrammierSprachen, die es gibt.

• Python ist leicht erlernbar.
• Python-Programme sind gut lesbar (liest sich wie PseudoCode).
• Python benötigt keine Blockklammern wie z.B. die geschweiften Klammern in SpracheCee oder BEGIN und END in SprachePascal. Die zur Lesbarkeit ohnehin übliche Einrückung definiert gleichzeitig die Blockstruktur (OptischeSemantik). Diese Art der Syntax ist relativ einzigartig (siehe WardsWiki:IndentationEqualsScope) und schaltet viele Fehlerquellen aus.
• Durch die dynamische Typbindung (alles ist ein Objekt) sind in Python geschriebene Module besonders gut wiederbenutzbar.
• Python-Programme sind in der Regel um Faktoren kürzer als in traditionellen Sprachen (wie z.B. SpracheJava) geschriebene Programme, die dasselbe leisten.
• Python ist auf allen heute verbreiteten Plattformen verfügbar (Unix, Linux, QNX, Windows, MacOs, ja sogar PalmOs? (noch mit Einschränkungen) und MicroSoft .NET, aber auch für ältere Betriebssysteme wie OS/2, Amiga, Psion5 (EPOC).
• Es sind zwei OpenSource Implementierungen vorhanden (CeePython und Jython). CeePython ist ein in SpracheCee geschriebener und extrem portabel programmierter Interpreter, der quasi überall zum Laufen gebracht werden kann, wo zumindest irgendein C-Compiler zur Verfügung steht.
• Python wird aktiv weiter entwickelt, wobei der Aufwärtskompatibilität existierender Anwendungen besonderes Gewicht eingeräumt wird. Alle Funktionen und Neuerungen sind in der Dokumentation mit der Version ihrer Einführung gekennzeichnet.
• Die Lizenz erlaubt die Verwendung für KommerzielleSoftwareProjekte?
• Die Implementierung ist sehr ausgereift und nahezu fehlerfrei.
• Python kommt inklusive Batterien: Die Standard-Bibliothek enthält fertige Module für sehr viele Problemklassen, die ausserdem hervorragend und präzise dokumentiert sind.
• Der interaktive Interpreter eignet sich auch als Taschenrechner. Einfache Programme können direkt ohne einen Editor ausprobiert werden.
• Der Interpreter kann in andere Anwendungen eingebaut werden und eignet sich so z.B. auch als SkriptSprache für erweiterbare Textverarbeitungs-, Tabellenkalkulations- oder CAD-Anwendungsprogramme.
• Python eignet sich für fast alle Anwendungsprobleme
• Python ist besonders geeignet für RapidPrototyping
• Nahezu alle bekannten Datenbanken lassen sich über ein gemeinsames API ansprechen.
• Es gibt Anbindungen an eine Vielzahl von GUI-Toolkits.
• Ganz abgefahren ist PyPy, eine noch unvollständige Implementierung in Python selbst.

• bislang kein native Code-Compiler verfügbar.
• zeitkritische Anwendungsteile können manchmal nur durch Umschreiben in andere ProgrammierSprachen beschleunigt werden.
• einzelne Internet-Provider haben verpennt und unterstützen Python-CGI noch nicht.

• Für Emacs (EmacsFamilie) gibt es einen sehr guten Python-Mode (EmacsMode).
• Auch jEdit (wenn ich nicht Vim nehme, nehme ich jEdit) hat einen Python-Mode ( http://jedit.org) -TomTom

• /Psyco
• /Aktuelles
• /FürJavaEntwickler

Frage:

Das liest sich ja fast wie eine Beschreibung von SprachePerl. Kann jemand vielleicht mal kurz zusammenfassen, was da Vor- und Nachteile sind?

Antwort:

http://www.sschwarzer.net/python/perlpy_vortrag.html ist ein deutschsprachiger Artikel, der Perl und Python vergleicht.

http://www.python.org/doc/Comparisons.html

vergleicht Python mit diversen anderen Programmiersprachen, u.a. Perl.

Ein etwas humorig gemeinter Vergleich ist der folgende Text:
http://www.python.org/doc/Humor.html#yoda ;-)

Dumme Frage:

Einrückungen tendieren beim Wechsel zwischen verschiedenen Editoren (IDEs, Betriebssystemen) zu einer gewissen Unzuverlässigkeit. Klammern eliminieren zwar nicht das optische Problem, aber zumindest verändert sich die Programmlogik nicht. Wie löst Python dieses Problem?

Antwort:

Es gibt keine dummen Fragen; allenfalls unangebrachte. ;-) Aber im Ernst: Probleme kann es eigentlich nur dann geben, wenn ein Text-Editor Tabulatoren (ASCII CHR(9)) mit Leerzeichen (ASCII CHR(32)) vermischt und dann ausserdem die Breite eines Tabulators anders als mit den historisch vorgegebenen 8 Leerzeichen interpretiert wird. Dieses Problem kann auftreten. Aber in der Regel verursacht es dann sofort so einen Haufen von Syntaxfehlern beim Übersetzen, dass es augenblicklich offensichtlich wird. Zusätzlich enthält die Python-Distribution selbst Werkzeuge wie z.B. tabnanny.py mit denen die unabsichtliche Vermischung von Tabulatoren und Leerzeichen leicht erkannt werden kann. Das in der Python-Distribution enthaltene IDE namens idle benutzt diesen Modul in seinem eingebauten Text-Editor selbst. Professionelle IDEs wie z.B. PythonWorks enthalten ähnliche Mechanismen. Für andere populäre Editoren wie vi oder emacs gibt es spezielle Python-Modi, die von vorneherein neben Einfärbung von Schlüsselwörtern z.B. auch für das Expandieren von Tabs sorgen. Ich persönlich bevorzuge den VIM (Vi IMproved; http://www.vim.org; siehe TextEditoren) -- PeterFunk

D. h. dass das Problem grundsätzlich existiert und eine gewisse Vorsicht geboten ist. Am besten eine spezialisierte IDE benutzen?

Nein: In der Praxis kann jeder normale Texteditor benutzt werden. Viele Leute machen unter Windows sogar ihre ersten Schritte mit Hilfe von notepad.exe. Meiner Meinung nach sind IDEs wohl etwas für Weicheier. ;-) Aber im Ernst: Eine IDE kann schon einigen Komfort bieten: z.B. einen ClassBrowser (KlassenDuscher? ? wohl eher KlassenDurchstöberer?..., to browse = blaettern, schmoekern, durchstoebern, to shower = duschen, scheint ein typischer false friend zu sein) oder eine die Anzeige der Parameter einer Methode oder Funktion in einer BalloonHelp?, direkt nachdem man den Funktionsnamen im Editor eingetippt hat. Das bietet ein normaler Editor wie z.B. der oben erwähnte VIM natürlich nicht. -- PeterFunk

Auch ich verwende normalerweise VIM. Übrigens kenne ich einen normalen Editor, der auch einen KlassenBrowser für Python mitbringt: Emacs (EmacsFamilie) mit PythonMode, bzw. XEmacs, der diesen standardmäßig dabei hat. -- GerhardHäring

Falls es jemanden interessiert, hier mal meine Erfahrungen konkret mit Python und allgemein mit dynamischer Typisierung (StatischeOderDynamischeTypisierung). Unter anderem zur Unterstützung der Arbeit im Fachschaftsrat suchte ich einst eine Sprache mit der man leicht Texte verarbeiten kann. Da wurde mir - natürlich - zuerst die SprachePerl empfohlen. Als dessen Dokumentation gleich mit der Beschreibung von Ausnahmen von Regeln anfing, habe ich das schnell wieder sein gelassen. Der nächste Versuch galt Python, und ich war mit der Funktionalität und der Syntax recht zufrieden. Die Modularisierung kam mir von der SpracheModula? her sehr bekannt vor. Listen und Hashes sind in der Sprache integriert und so konnte ich schnell mit dem Programmieren loslegen.

Python ist dynamisch getypt. Objektelemente entstehen genau wie globale Variablen dadurch, dass man sie beschreibt, d.h. ich weiß nie genau, was ein Objekt eigentlich für Elemente besitzt. Da ich in einem Funktionskopf nicht zwischen Übergabe als Verweis (CallByReference?) und Übergabe als Wert (CallByValue?) unterscheiden kann, habe ich mich gefragt, wie der Python-Interpreter sie denn nun übergibt. Dann habe ich gelernt, dass es veränderliche und unveränderliche Typen gibt. Erstere (zum Beispiel Listen und Objekte) werden immer als Verweis übergeben, zweitere (Skalare und Tupel) immer als Wert. Der Typ entscheidet sich aber erst zur Laufzeit und damit bezwecken die Skriptsprachenverfechter anscheinend auch Polymorphie, also dass die gleiche Routine beispielsweise sowohl für Listen als auch für Felder verwendet werden kann. Rückgabewerte können in Python ignoriert werden (können ja auch nicht deklariert werden) oder nicht vorhandene Rückgabewerte können benutzt werden. Diese Eigenschaft habe ich schon an der SpracheCee gehasst. Zweiteres gibt schwer nachvollziehbare Fehler, denn eine Funktion ohne Rückgabewert gibt immer None (sowas wie NIL) zurück und damit arbeitet das Program erst einmal weiter. Der Fehler fällt erst dann - wenn überhaupt - auf, dass man mit None ein paar Dinge tut, die man eigentlich mit der als Rückgabe erwarteten Liste tun wollte. Eine Funktion, in der man nur ein return vergessen hat, führt bereits zu dieser Situation.

Ich habe Python im Wesentlichen für drei Sachen benutzt (eine HTML-/LaTeX-Aufbereitung für Sitzungsprotokolle, eine Fragebogenauswertung und einen Online-Übersetzer für HTML-Seiten), aber als die Projekte größer wurden, und eigentlich wurden sie immer größer, hat mich die dynamische Typisierung jämmerlich im Stich gelassen. Wie soll ich denn eine Datenstruktur ändern, wenn es keine Möglichkeit gibt, den entstandenen Rissen im Gebäude systematisch auf den Grund zu gehen? Nicht einmal Variablen- oder Objektelementnamen kann ich gefahrlos ändern, denn ich kann die falschen Zugriffe auf nicht mehr vorhandene Elemente nicht sicher entdecken! Wer seine Programme immer nur erweitert und nie überarbeitet, den stört das vielleicht nicht.

Ich habe inzwischen manche Programmteile von Python in die funktionale SpracheHaskell portiert. Haskell sollte Python-Benutzern zumindest als Ideenlieferer bekannt sein, denn solche Sachen wie map und Listenerzeugung wurden dort abgeschaut. Nicht nur dass Haskell dumme Fehler schnell durch Typentests aufdeckt, noch bevor ich den ersten Testfall ersonnen habe, nein die Programme werden auch deutlich knapper und die Bibliotheksfunktionen zum Beispiel zur Textverarbeitung sind weit flexibler und besser durchdacht. Ich kann alles im interaktiven Modus des GlasgowHaskellCompilers? ausprobieren, ich muss mich nicht mit Initialisierungen herumärgern, weil es keine globalen Variablen gibt. Die regulären Ausdrücke habe ich in Haskell bislang noch nicht vermisst, auch Indizierung von Listenelementen zur Listen- oder Textverarbeitung brauche ich kaum. Ich kann die Aufgabe in logische Schritte zerlegen, etwa: HTML-Gerüst analysieren, nach bestimmten HTML-Attributen suchen, eigentlichen Text verarbeiten. Ausgeführt wird es dagegen, wie der Text kommt, vom Textanfang zum Textende. Stockt die Texteingabe, wird der Ausgabetext soweit berechnet, wie es die Eingaben zulassen. Das ist die Segnung der verzögerten Auswertung und die wird man in imperativen Sprachen kaum bekommen können. Aus dem Haskell-Blickwinkel kommt mir Python inzwischen wie Spielzeug vor. Haskell ist vielleicht nicht so leicht erlernbar, aber das ist wahrscheinlich auch gut so, denn was soll ich mit Haskell-Programmen im Perl- oder Python-Stil anfangen? -- HenningThielemann

Auch statische Typisierung kann einen jämmerlich im Stich lassen. So oder so benötigt man ein Werkzeug, um Fehler schnell zu finden und korrigieren zu können. Das Problem mit Perl, Python, Ruby und Co ist, dass eine IDE fehlt, mit der sich die Vorteile der dynamischen Typisierung ausnutzten lassen, ohne, dass die Dynamik einem ständig in den Rücken fällt. Ich lasse meine Programme deshalb vorzugsweise direkt im Debugger laufen. Ich habe gehört, XP-Spezi KentBeck programmiert sein 'Test first' auch nur im Debugger. Gib den Skriptsprachen noch zwei drei Jahre, dann wird es auch dort entsprechende Programmierumgebungen geben. Wenn du mit Haskell besser klar kommst als mit Python, nimm solange eben Haskell. Solange das Typkonzept die Sprache nicht verhunzt, habe ich nichts gegen Typ-Annotationen. -SDö

"XP-Spezi KentBeck programmiert sein 'Test first' auch nur im Debugger" Wo haste denn das gelesen? --bs

Nicht gelesen, das hat mir ein Kollege erzählt. Der war auf einem Vortrag, wo Kent Beck das vorgeführt hat. Natürlich nicht mit Python sondern mit Smalltalk, aber darauf kommt es letztlich nicht an. In Eclipse für Java ist ja auch schon ein inkrementeller Compiler am Start.

PS: Gerade ist dazu ein Artikel bei Newsforge erschienen: Evidence that Python is advancing into the enterprise

So klappt's --TomTom

So auch: http://www.wikiservice.at/dse/wiki.cgi?search=ython&text=off&word=off

Grund: es gibt andere Default-Parameter für das Formular (die Lösung von TomTom) bzw. für die Kommandozeile. -- HelmutLeitner