Das deutsche Python-Forum

Derzeit wird das "Kompendium der Web-Programmierung" von Thomas Walter (Prof. Dr.) für 10 Euro verramscht (Normalpreis 66,95 Euro).

Das Buch ist optisch und vom Material her sehr hochwertig gemacht, hinterlässt insgesamt einen "wertigen Eindruck". Nach einigen Kapiteln allgemeiner Grundlagen folgt ein Teil "Serverseitige Webprogrammierung" mit je einem eigenen Kapitel über Perl, PHP, Python und Ruby; außerdem noch eins über CGI und SSI. Dann ein Teil "clientseitige Programmierung" mit Kapiteln zu JavaScript, Ajax und Flash. Das Kapitel über Java-Applets trägt die Überschrift "Gescheiterte Technik: das Applet".

In einem weiteren Teil gibt es dann u.a. noch Kapitel zu fastCGI und verschiedene Frameworks, u.a. PEAR, django und Ruby on Rails.

Für jemanden wie mich, der davon wenig mehr als nichts versteht, eine preiswerte Gelegenheit, sich ein wenig Überblickswissen zu verschaffen.

Als erstes habe ich mir das Kapitel über Python angesehen (davon verstehe ich etwas mehr als etwas weniger als nichts). Und die erste Freude über das vermeintliche Schnäppchen trübte sich:

Das Kapitel basiert auf Python 2.5 - das ist okay. Allerdings wird print äußerlich wie eine Funktion behandelt (immer schön Klammern drum) und nirgends findet sich ein Hinweis darauf, dass print keine Funktion ist. Auch bei bedingten Anweisungen und in Schleifenköpfen: Jede Bedingung eingeklammert, auch wenn es nur eine ist ...

Als Eingabemöglichkeiten werden input() und raw_input() genannt. An keiner Stelle findet sich jedoch ein Hinweis darauf, worin sie sich unterscheiden. Man gewinnt den Eindruck, als wären es äquivalente Funktionen. Von der Problematik, die mit input() verbunden ist, ganz zu schweigen.

Bei der Vorstellung der numerischen Datentypen wird unterschieden zwischen "plain integer" (32 Bit) und "long integer", gekennzeichnet durch "L", die intern mit 64 Bit gespeichert werden. Das Integerzahlen quasi beliebig groß sein dürfen - kein Wort davon.

Zur Typüberprüfung wird type() empfohlen. Auf die Existenz von Dictionaries wird hingewiesen und ein Beispiel gezeigt. Es wird aber konsequent von "assoziativen Listen" gesprochen und das dict bekommt im Beispiel den Namen "hash". Nicht mal ein Hinweis darauf, dass das in Python dictionary heißt und es den Typ dict gibt.

Im Abschnitt über Dateien findet man read(), readline(), readlines(), write(), writelines() und flush(). Kein Wort darüber, dass man über Dateien iterieren kann.

Bezeichner werden in Camelcase notiert. Attribute können vom Zugriff von außen "geschützt" werden. Eine private Variable hat so auszusehen: __dummy_. Weiter gehts: __init__() ist der Konstruktur, __del__() der Destruktor.

Ich glaub, ich höre jetzt auf. Ist aber sicher noch nicht alles.

Und nun? Was mache ich mit den restlichen 550 Hochglanzseiten des Buchs? Sie behandeln ja zum größten Teil Dinge, die mir neu sind und über die ich mit Hilfe des Buches etwas lernen wollte. Woher weiß ich, dass die Inhalte in diesen Kapiteln nicht von derselben schlechten Qualität sind wie das Python-Kapitel?

Vielleicht kennt einer von euch das Buch und kann mir zu dem ein oder anderen Kapitel eine kurze Qualitätseinschätzung geben.

In iX 3/2008 gibt es ein Review zu dem Buch, das mit dem Fazit "hat das Zeug zu einem Klassiker" schließt. Dem Rezensenten hat's offenbar gefallen.

Ich glaube, man kann nicht erwarten, dass ein Professor (wenn auch sicherlich zusammen mit seinen Assistenten), jede der vorgestellten Sprachen im Detail kennt und deren Idiomatik benutzt. Ihm sind wahrscheinlich allgemeinere Konzepte wichtiger und wenn dann ein Dictionary Hash (wie bei Ruby) heißt, dann ist das ein ärgerliches Detail, aber für das Verständnis davon, wie denn nun die Entwurfsmuster und Technologien der Web-Entwicklung sind, reichlich egal. Zum Lernen der Programmiersprachen ist das Buch damit wohl nicht geeignet.

Ob man so ein Buch braucht, kann ich nicht beurteilen. Gibt GCI als Konzept so viel her (oder wird auch HTTP und/oder HTML erklärt?) das man dazu ein theoretisches Grundlagenbuch braucht?

Was in der Rezension noch positiv erwähnt wird, ist, dass das Buch 2008 aktuell gewesen wäre und z.B. zwar schon Safari für Windows erwähnen würde, aber auch darauf hinweise, dass der Browser noch neu und unausgereift sei. Inzwischen sind fast zwei Jahre vergangen und solch Aussagen nicht mehr zutreffend. Chrome ist noch neuer und schon in der vierten Version. Die Zeit vergeht schnell. Kann da überhaupt noch ein gedrucktes Buch mithalten?

Stefan

sma hat geschrieben:Ich glaube, man kann nicht erwarten, dass ein Professor (wenn auch sicherlich zusammen mit seinen Assistenten), jede der vorgestellten Sprachen im Detail kennt und deren Idiomatik benutzt.

Sehe ich auch so. Aber dann sollte man vielleicht Experten für bestimmte Teilbereiche hinzuziehen, wenn man Themen in einem Buch behandelt, von denen man selbst nicht so viel versteht.

Zum Lernen von Python ist das Buch in jedem Fall ungeeignet, aber das ist auch nicht das Anliegen des Buches, denke ich. Dazu fallen die Kapitel über die einzelnen Programmiersprachen zu kurz aus. Andererseits ist zumindest das Python-Kapitel (die anderen habe ich noch nicht angesehen) dann auch wiederum an einigen Stellen so konkret, dass man schon annehmen muss, dass der Autor davon ausgeht, dass einen die Lektüre zum Schreiben von Python-Skripten befähigt, weil es über das Vorstellen allgemeiner Sprachkonzepte hinausgeht.

Ja, das Buch ist nicht mehr ganz aktuell (2 1/2 Jahre alt), deshalb vermutlich auch für 10 Euro zu haben. Das stört mich aber nicht weiter, weil es mir mehr um allgemeine Grundlagen und Überblickswissen geht. Das findet man auf jeden Fall in dem Buch - von welcher Qualität auch immer.

sma hat geschrieben:Ich glaube, man kann nicht erwarten, dass ein Professor (wenn auch sicherlich zusammen mit seinen Assistenten), jede der vorgestellten Sprachen im Detail kennt und deren Idiomatik benutzt.

Ist es dann nötig so etwas dann in ein Buch zu schreiben? Ich meine, wenn man's nicht kann, dann kann man es auch sein lassen. Ich meine: es ist nicht so schwer jemanden aus der Community zu finden der es korrekturliest. Das Django Book und Programming Scala haben sogar den Weg eines Community-Reviews gewählt, ebenso wie Real World Haskell - das ist natürlich aus Verlagssicht riskanter, aber wenn ein Verlag niemanden findet der den Text gegenprüft, dann ist das arm.

Ich stimme da numerix zu: wenn er sagen kann, dass die Qualität des Python-Kapitels nicht gut ist, woher soll er dann wissen wie gut der Rest ist?

Was Buchdokumentation angeht: ich mache jetzt seit circa 3 Wochen OCaml. Lerne es aus eine Skript von vor zwei Jahren, einem Buch von 1999 dass OCaml 2 beschreibt und vor allem: halte Kontakt zu Leuten die OCaml richtig gut können: #ocaml. Die Code-Reviews dort haben mir echt eine Menge geholfen und ich war teilweise fasziniert was man aus dem Code noch herausholen konnte. Sowas könnte der Autor ja theoretisch durchaus auch machen.

Ich würde ja auch zu der Aussage tendieren: Erst über etwas schreiben, wenn man's auch beherrscht, aber selbst kein Buch je geschrieben habend, bin ich vorsichtig mit Kritik. Häufig ist das Problem ja nicht, dass man etwas nicht kann, sondern dass man nicht weiß, das man's nicht kann.

Stefan

Ich habe inzwischen ein bisschen weiter im Buch (quer)gelesen und es wird recht deutlich, dass der Autor von Java herkommt. Das erklärt sicher einen Teil der Defizite des Python-Kapitels, aber rechtfertigt es nicht.

Allein die Lektüre der ersten Kapitel des Python-Tutorials hätte genügt, um den größten Teil der Mängel des Python-Kapitels zu beheben.

Was ich absolut nicht nachvollziehen kann: Es werden input() und raw_input() (sogar an zwei verschiedenen Stellen im Buch) einfach nur als Eingabefunktionen benannt, einmal mit dem Hinweis, üblicherweise würde "raw_input()" bevorzugt, ohne zur erwähnen, worin sich beide unterscheiden. Jedem mitdenkenden Leser stellt sich doch an dieser Stelle die Frage, worin sich beide unterscheiden oder ob sie sich gar nicht unterscheiden und warum es dann zwei Funktionen dafür gibt und warum dann auch noch die eine üblicherweise bevorzugt wird. So was kann ich gar nicht leiden.

Vielleicht solltest du eine Rezension schreiben und sie dem Autor auch zukommen lassen. Schließlich gibt er sein Defizite auch an seine Studenten weiter.

gkuhl hat geschrieben:Vielleicht solltest du eine Rezension schreiben und sie dem Autor auch zukommen lassen.

Das Buch als ganzes kann ich ja nicht beurteilen, weil ich von den meisten Dingen, die behandelt werden, (noch) nicht genug verstehe. Für eine Rezension genügt das nicht. Ich könnte den Verfasser aber zumindest auf einige Defizite im Python-Kapitel hinweisen. Vielleicht mache ich das mal ...

Edit 1:
Ich sehe gerade, dass die Quelltexte zu den verwendeten Beispielen auch im Netz verfügbar sind: http://ceres.informatik.fh-kl.de/webkom ... al/python/
Man braucht sich eigentlich nur das erste Beispiel Book.py anzusehen, um einen Eindruck zu gewinnen ...

Edit 2:
Ich habe den Verfasser eben per E-Mail auf diesen Thread hingewiesen.

Interessant finde ich ``__dummy_``. Warum ein abschließender Unterstrich? Ich meine doppelter Unterstrich "versteckt" die Variable und nicht der drangehängte.

jbs hat geschrieben:Interessant finde ich ``__dummy_``. Warum ein abschließender Unterstrich? Ich meine doppelter Unterstrich "versteckt" die Variable und nicht der drangehängte.

Ich vermute, damit soll die besondere "Privatheit" des Attributs noch einmal "unterstrichen" werden ...

Aber im Grunde ist dieser letzte Unterstrich noch mit das Harmloseste in diesem Beispiel-Code (Book.py):
Selbst jemand, der so gut wie nichts von Python versteht, entdeckt hier Dinge, die nicht stimmig oder einfach nur peinlich sind. Und wer auch nur ein bisschen mehr als wenig von Python versteht, dem dreht sich doch überhaupt der Magen um bei diesem Stück Code.

Wofür wird denn string importiert? Macht man das in Java so?

Selbst das Openbook sieht ``__x`` als private an und verzichtet auf einen weiteren Unterstrich.

numerix hat geschrieben:

jbs hat geschrieben:Interessant finde ich ``__dummy_``. Warum ein abschließender Unterstrich? Ich meine doppelter Unterstrich "versteckt" die Variable und nicht der drangehängte.

Ich vermute, damit soll die besondere "Privatheit" des Attributs noch einmal "unterstrichen" werden ...

PEP8 sagt, dass die mindestens einen fuehrenden Unterstrich haben muessen und maximal einen nachfolgenden haben duerfen. Vielleicht hatter das missverstanden ...

Aber der Code ist ja wirklich grausig, Die Kommentare sind noch schlimmer.

Am besten hat mir ja der Kommentar direkt über der `__str__()`-Methode gefallen: ``### __str__-Methode ###``. Sehr erhellend.

BlackJack hat geschrieben:Am besten hat mir ja der Kommentar direkt über der `__str__()`-Methode gefallen: ``### __str__-Methode ###``. Sehr erhellend.

Wenigstens stehts nicht im Doc-String

Habe noch ein bisschen in den Beispielen und den Folien zum SS09 geschmökert. Jaaa, und bei den MySQL-Beispielen werden natürlich SQL-Anfragen aus Zeichenketten zusammengebastelt! SQL-Injection ick hör Dir trapsen. Und die ``while``-Schleife "über" das Ergebnis ist auch nicht schön.

``form.__contains__('zufall')`` ist auch etwas das man durch das Studium des Tutorials vermeiden könnte.

HTML mit Zeichenketten zusammenbasteln ist nicht schön, aber für die ersten CGI-Schritte vielleicht noch erträglich -- was nicht für Zeichenketten gilt, die in " eingeschlossen sind und selber zig "escape"te \" enthalten. Auf die Idee solche Zeichenketten in ' einzufassen, hätte einen das Tutorial sicher auch bringen können.

Ich glaube ich habe auch keine Verwendung des ``%``-Operators bei Zeichenketten gesehen.

Zu den Folien: Python und Ruby sind beliebt für *CGI*-Programmierung? I don't think so. Und Java soll dafür angeblich nicht möglich sein!?

jbs hat geschrieben:Wofür wird denn string importiert? Macht man das in Java so?

Nein, selbst dort nicht. ``java.lang.String`` ist ohne weiteres erreichbar.

Das der Beispielcode schlecht ist, beschränkt sich nicht nur auf Python. Das Book-Beispiel für Ruby und JavaScript ist ebenfalls nicht idiomatisch für diese Sprachen. Ich tippe darauf, dass die Beispiele mit der festen (und IMHO falschen) Überzeugung geschrieben wurden, dass es eine Semantik gibt und die Syntax austauschbar ist. Also sehen wir das selbe (Java-)Programm mal in Python-Syntax, mal in Ruby-Syntax und mal in JavaScript-Syntax.

Das Problem ist, zu erklären, warum es okay ist, dass die eigentliche gute Idee von Java, private Attribute und öffentlichen Zugriffsmethoden zu kombinieren, nicht für Python sinnvoll genug ist, dass man es dort auch macht. Oder das in Ruby zwar Zugriffsmethoden (dank Smalltalk-Erbe) notwendig sind, man diese aber anders nennt und über `attr_reader` erzeugen lässt und niemals selbst baut. Das mag alles aufwendiger sein und für das Ziel, Webprogrammierung nahezubringen, nicht notwendig, als es einfach immer wie (einmal erklärt?) in Java zu machen.

Beispiel? Statt http://ceres.informatik.fh-kl.de/webkom ... by/Book.rb würde ich's so schreiben: http://paste.pocoo.org/show/156675/

Das Django-Beispiel ist für eine alte Version (ich rate 0.95) geschrieben und selbst da hätte man glaube ich die View-Funktionen einfacher schreiben können. Schaut man auf die Datei-Daten, sieht man, dass das alles von 2005-2007 geschrieben wurde. Gleiches gilt für das Rails-Beispiel. Das ist definitiv nicht Rails 2.x.

Stefan