
Liebe Listenmitglieder, mit großem Interesse habe ich die Diskussion über mein neues Buch "Objektorientierte Programmierung mit Python" gelesen. Ich habe sie per Zufall im Archiv der Mailingliste (4. Quartal 2003) gefunden (http://starship.python.net/pipermail/python-de/2003q4/thread.html#4385). Vielleicht interessien Sie einige Anmerkungen und Hintergrundinformationen des Autors. Ich nehme die "Intialisierungsmail" des Diskussionsfadens von Klaus Meyer als Ausgangspunkt.
Das Buch "Objektorientierte Programmierung mit Python" hat knapp 600 Seiten. Das Layout ist übersichtlich und klar, das Inhaltsverzeichnis ausführlich. Der Index scheint mir etwas knapp zu sein. <<<
MW: Ich glaube auch, dass ein guter Index ein wichtiges Qualitätsmerkmal ist und werde ihn bei der Zweitauflage gründlich überarbeiten und -soweit es der Verlag mir erlaubt - erweitern. Mit über 900 Stichwörtern hat der Index von "OOP mit Python" aber durchaus einen Umfang, der bei Lehrbüchern dieser Art üblich ist.
Etwa die Hälfte des Buches ist eine Einführung in Python (es wird schon V 2.3 verwendet), wobei der Autor einen Schwerpunkt "auf die Erarbeitung von Konzepten der Objektorientierung" gelegt haben will. In der zweiten Hälfte wird relativ ausführlich Tkinter behandelt, außerdem einige andere Themen, zB CGI-Programmierung, Internet, Datenbanken, Threads, Fehlerbehandlung usw... Außer den unvermeidlichen Listings enthält das Buch auch einige erklärende Grafiken, einfache UML-Diagramme und einige EBNF-Grammatiken zur Syntax von Python. <<<
MW: Das Buch soll eine Einführung in die Objektorientierte Programmierung sein, also damit auch eine Einführung in die Programmierung als solche. Und damit müssen auch Konzepte wie Operatoren, Kontrollstrukturen etc. besprochen werden, die nichts "spezifisch objektorientiertes" in sich bergen. Die "richtige" objektorientierte Programmierung beginnt ja eigentlich erst dann, wenn man eigene Klassen definiert. Damit beginnen wir in der Mitte des Buches. Im ersten Teil werden nur vorgegebene Klassen verwendet. Ich habe Wert darauf gelegt, von Anfang an die Begrifflichkeit der Objektorientierten Programmierung möglichst sauber zu verwenden. So ist die Rede von "Objekten der Klasse File", der Begriff des "Datentyps" wird in Beziehung zum Begriff der "Klasse" gesetzt, wir gehen auf die Identität von Objekten ein, es werden Methoden von String- oder Dictionary-Objekten verwendet ..., um nur einige wenige Beispiele zu nennen. Insofern zieht sich die objektorientierte Denkweise wie ein roter Faden durch das ganze Buch - auch im ersten Teil.
Der Autor pflegt einen sachlichen Still, die Beispiel, soweit ich sie mir angesehen habe, wirken aber etwas "hölzern", so wie man sie aus manchen Schulbüchern kennt. Jedes Kapitel hat am Schluß einen Aufgabenblock und die Lösungen gibt es auch gleich dahinter. <<<
MW: Ich glaube, ich habe so eine ungefähre Ahnung, was mit "hölzern" gemeint ist, vielleicht: nüchtern, ohne Verzierungen ... Grundsätzlich: Ein Lehrbuch lebt von guten Beispielen. Ich habe versucht, die Beispiele thematisch so zu wählen, dass sie reale Anwendungsfelder der Informatik berühren. Auf der anderen Seite sollten die Listings möglichst kurz und übersichtlich bleiben, um eine optimale Lesbarkeit zu gewährleisten. Bei der Entwicklung der Beispiel war es manchmal so, dass der erste Entwurf vielleicht fünf Seiten Programmtext umfasste, dann immer weiter gekürzt und auf das Wesentliche reduziert wurde, bis dann am Ende nur noch eine Seite übrig blieb. Beim Leser sollte die Idee entstehen, dass man das Beispielprogramm zu etwas wirklich Brauchbaren weiterentwickeln könnte.
Auf Grund des Titels hätte ich ein Buch erwartet, welches schon von Python-Grundkentnissen beim Käufer ausgeht und nun die ganzen Besonderheiten der "Objektorientierung" vertieft. Der Autor mag die "Objektorientierung" mehr im Fokus haben, als das in anderen Büchern der Fall ist, aber im Grunde scheint es mir im wesentlichen eine allgemeine Einführung in Python (+ einiger Python-Libs wie zB Tkinter) zu sein. <<<
MW: Viele Universitätscurricula gehen so vor. Zuerst ein Kurs über (imperative) Grundkonzepte der Programmierung, dann ein Fortgeschrittenenkurs über OOP. Wir haben versucht, sowohl (ambitionierte) Einsteiger als auch Fortgeschrittene anzusprechen. (So steht es übrigens auch auf dem Buchumschlag) Das bedeutet aber auch (wie schon gesagt), dass zunächst grundlegende Konzepte angesprochen werden, die für Fortgeschrittene vielleicht stellenweise langweilig sind. Allerdings habe ich auch schon von erfahrenen Programmierern gehört, dass sie auch im ersten Teil des Buches etwas dazu gelernt hätten :-)
Obwohl schon Pyton V2.3 verwendet wird, werden neue Python Funktionen - wie zB Generatoren - nicht behandelt.
MW: Das Buch sollte maximal 600 Seiten haben. Es mussten also Schwerpunkte gesetzt werden. Ein Zusatzkapitel ist noch auf der CD. Aber viele spezielle Themen fielen dem "Rotstift" zum Opfer, darunter etwa die Anbindung von Python-Skripten an MySQL-Datenbanken und C-Programme, XML, Generatorfunktionen, Iteratoren etc. Um die Generatorfunktionen tut es mir schon deswegen Leid, weil ich jahrelang an einem Lehrstuhl gearbeitet habe, bei dem das Rechnen mit unendlichen Objekten ein zentrales Forschungsgebiet war.
Zum Schluß noch eine merkwürdige Sache (die wohl kein Zufall sein kann!): In allen Programmen werden keine Umlaute verwendet und es gibt auch keine tieferen Informationen zum Thema Unicode (trotz eines eigenen Kapitels über Zeichenketten)! Überall werden die Umlaute konsequent umschrieben (ae, ue usw.). Beim Buch ist auch eine CD dabei, auf der alle Beispielsourcen enthalten sind. Ich habe die durchsucht, keine Umlaute! Warum das so ist, weiß ich nicht, aber gerade über Unicode hätte ich mir ein ausführliches Kapitel gewünscht. <<<
MW: Entscheidend für mich ist die Lesbarkeit von Programmbeispielen. Deshalb habe ich die Umlaute und ß meist umschrieben. Beachten Sie: Listings in einem Buch sind Texte, die gelesen werden. Es bereitet einfach gr\xf6\xdfere M\xfche einen Text zu lesen, in dem Nicht-ASCII-Zeichen durch Escape-Sequenzen codiert sind. Zum Thema Unicode: Ich hatte gedacht, mit einer Seite die Essentials ausreichend gut behandelt zu haben. Aber interessant zu erfahren, dass hier mehr Information gewünscht wird. Soweit meine Anmerkungen. Wenn Sie Fehler finden oder sonstige kritische Kommentare haben, können Sie mir auch gerne direkt schreiben. Es wird in Kürze auf der Web-Site von mitp eine Errata-Seite zu diesem Buch angelegt. Frohe Weihnachten und alles Gute im Neuen Jahr Michael Weigend michael.weigend@fernuni-hagen.de _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

Hallo!
Warum das so ist, weiß ich nicht, aber gerade über Unicode hätte ich mir ein ausführliches Kapitel gewünscht. <<< ... Zum Thema Unicode: Ich hatte gedacht, mit einer Seite die Essentials ausreichend gut behandelt zu haben. Aber interessant zu erfahren, dass hier mehr Information gewünscht wird.
ich glaube wirklich, ein gutes Kapitel zum Thema Unicode wäre sehr hilfreich (und da sind schon mehrere Seiten vonnöten!). Das Thema hat nämlich viele Aspekte. Hier in der Mailingliste gab es dazu schon mehrfach Diskussionen. Gerade sehe ich auch einen unvollständigen Thread "Alptraum Unicode". Die Python-Unicde-Implementierung ist meiner Meinung nach mindestens "undurchsichtig". Ich gehe da aber lieber nicht weiter drauf ein, damit habe ich mich schon "unbeliebt" gemacht. Die vielen alten Diskussionen kann man in dieser Liste ja nachlesen. Jedenfalls wäre ein Kapitel über das Thema hilfreich, es könnte vielleicht sogar den Verkauf eines Python-Buches ankurbeln. :-) Nur wird es nicht gerade einfach sein, das Unicodekapitel in Python verständlich und hilfreich aufzuhellen!! Eine Herausforderung für einen Autor also ;-) -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

kgm wrote:
Die Python-Unicde-Implementierung ist meiner Meinung nach mindestens "undurchsichtig". Ich gehe da aber lieber nicht weiter drauf ein, damit habe ich mich schon "unbeliebt" gemacht.
Das ist schade (beides: Dass Du glaubst, Dich "unbeliebt gemacht zu haben, und dass Du nicht erläutern willst, warum Du die Implementierung für "undurchsichtig" hälst). Die Unicode-Implementierung folgt einigen wenigen klaren Prinzipien: 1. Es gibt zwei String-Typen: <type 'str'> und <type 'unicode'>. Das sind völlig verschiedene Datentypen. 2. <type 'str'> repräsentiert Bytes (Listen von Werten zwischen 0 und 255). 3. <type 'unicode'> repräsentiert Zeichenketten (Buchstaben, Zahlen, Punkierung usw). 4. Zwischen <type 'str'> und <type 'unicode'> kann man umwandeln: a) str -> unicode: decoding b) unicode -> str: encoding Zur Umwandlung benötigt man stets und immer ein "Encoding". 5. Falls versucht wird, <type 'str'> und <type 'unicode'> ohne Konvertierung zu mischen, wird das "system default encoding" ('us-ascii') als Encoding verwendet. Diese Prinzipien halte ich nicht für undurchsichtig - deshalb die Bitte, näher zu erläutern. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

* Martin v. Loewis <martin@v.loewis.de>:
1. Es gibt zwei String-Typen: <type 'str'> und <type 'unicode'>. Das sind völlig verschiedene Datentypen.
Deshalb habe ich das nie Verstanden! Womöglich habe ich an den erklärenden Worten in Dokumentation und Büchern bisher immer vorbei gelesen. Falls es mir ab heute an einer Stelle auffallen sollte, werde ich die Autoren der Dokumentation um Verbesserung bitten, denn jetzt weiß ich, was den Texten immer gefehlt hat. Danke, Kai -- » kai weber _ http://www.glorybox.de _ icq 102024972 _ pgp 0x594D4132 _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

Am Montag 29 Dezember 2003 00:54 schrieb Kai Weber:
* Martin v. Loewis <martin@v.loewis.de>:
1. Es gibt zwei String-Typen: <type 'str'> und <type 'unicode'>. Das sind völlig verschiedene Datentypen.
Deshalb habe ich das nie Verstanden!
...Wenn es dich tröstet - Ich habe es auch erst jetzt verstanden. MfG Olaf _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

Olaf 'Ruebezahl' Radicke wrote:
Am Montag 29 Dezember 2003 00:54 schrieb Kai Weber:
* Martin v. Loewis <martin@v.loewis.de>:
1. Es gibt zwei String-Typen: <type 'str'> und <type 'unicode'>. Das sind völlig verschiedene Datentypen.
Deshalb habe ich das nie Verstanden!
...Wenn es dich tröstet - Ich habe es auch erst jetzt verstanden.
Ich habe jezt nicht den ganzen Thread durchgesucht, aber falls die Python-Unicode-FAQ bisher noch nicht erwaehnt wurde, dann ist es nun wirklich hoechste Zeit das nachzuholen! http://p-nand-q.com/python/unicode_faq.html -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

Hallo Martin,
Diese Prinzipien halte ich nicht für undurchsichtig - deshalb die Bitte, näher zu erläutern.
nun, wenn ich die undurchsichtigen genau Stellen kennen würde, dann wäre es ja nicht undurchsichtig! ;-) Aber, fällt es Dir nicht auf, wie oft dazu Fragen auftauchen, auch in c.l.p? Da ja auch häufig von Dir dazu Antworten kommen, müßte es Dir auffallen ;-) Und wie sich da lange Diskussionen hin + her entwickeln, die aber eigentlich nicht zu eindeutigen Antworten führen.
Die Unicode-Implementierung folgt einigen wenigen klaren Prinzipien: Die Regeln sind, glaube ich, weitgehend klar. Du bist aber nicht auf die Ausnahmen+Sonderregeln eingegangen. Gerade das wäre interessant. Wie Du hier und da schon erwähnt hast, wurde dies+das aus Gründen der Rückwärtskompatibilität eingebaut, damit alte Scripte weiter laufen. (Stichworte: Tkinter, das mal Bytestrings, mal Unicode zurückgibt, Textdateien, die sich ohne Encoding-Angabe lesen/schreiben lassen. Vermutlich noch andere Stellen, die ich noch nicht kenne (achja, was ist mit Filefunktion (open() usw.) bezgl. der Pfad/Filenamen mit Encoding? Irgendwas automatisch?)).
Mein Wunsch wäre, eine Liste mit allen diesen Ausnahmen. Das wäre bestimmt sehr hilfreich. Wo genau wird was wegen Rückwärtskompatibel gemacht? Schon mal Danke! PS: Die Tkinter-Eigenheit führt zB auch in IDLE zu Bugs. Wenn Unicode doch so klar und "durchsichtig" ist, warum passieren dann sogar den Entwicklern der Sprache solche Fehler? Für mich sind das Hinweise, das was "undurchsichtig" ist. -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

kgm wrote:
Aber, fällt es Dir nicht auf, wie oft dazu Fragen auftauchen, auch in c.l.p? Da ja auch häufig von Dir dazu Antworten kommen, müßte es Dir auffallen ;-)
Das fällt mir schon auf. Ich glaube jedoch, dass das nicht daran liegt, dass die Python-Implementierung undurchsichtig ist, sondern dass vielen Entwickler einfach die "richtige" Modellvorstellung fehlt. Sie hatten bisher nur mit einer einzigen Zeichenkodierung zu tun, und haben deshalb das Phänomen "Zeichensätze" bisher gar nicht wahr genommen. Das merkt man an Bemerkungen der Art, dass Byte-Strings "ASCII-Strings" genannt werden, selbst wenn dort nicht-ASCII-Zeichen vorkommen, die dann als "Sonderzeichen" bezeichnet werden, usw. Wenn das mentale Modell "es gibt mehr als einen Zeichensatz" sich verbreitet hat, ist auch die Python-Implementierung dieses Modells nicht mehr undurchsichtig.
Und wie sich da lange Diskussionen hin + her entwickeln, die aber eigentlich nicht zu eindeutigen Antworten führen.
Hmm. Wenn diejenigen, die Antworten, das Problem selbst nicht verstehen, kann das schon durchaus vorkommen. Immer häufiger lese ich aber die "richtigen" Antworten, die dann *immer* auch eindeutig sind.
Die Regeln sind, glaube ich, weitgehend klar. Du bist aber nicht auf die Ausnahmen+Sonderregeln eingegangen. Gerade das wäre interessant.
Bin ich. Es gibt die Sonderregel, dass man Bytestrings und Unicode-Strings "manchmal" kombinieren darf. Darüber hinaus gibt es in der Sprache keine Sonderregeln in Bezug auf Unicode. Allerdings muss man zusätzlich noch wissen, welche Parametertypen und Rückgabetypen irgendwelche Funktionen der Bibliothek haben. Das muss man einfach auswendig lernen, so, wie man auch gelernt hat, dass Integer + Integer ergibt Intger Integer + Float ergibt Float Liste + Liste ergibt Liste
Wie Du hier und da schon erwähnt hast, wurde dies+das aus Gründen der Rückwärtskompatibilität eingebaut, damit alte Scripte weiter laufen. (Stichworte: Tkinter, das mal Bytestrings, mal Unicode zurückgibt, Textdateien, die sich ohne Encoding-Angabe lesen/schreiben lassen.
Na ja - keine Regel der Sprache, sondern eben der Bibliothek. Die Bibliothek verändert sich auch stärker als die Sprache selbst. Gerade in Bezug auf Unicode ist zu erwarten, dass man in Zukunft Unicode-Strings an Funktionen übergeben darf, die heute nur Bytestrings akzeptieren; genauso, wie man heute an vielen Stellen long integers übergeben darf, wo vorher nur ints erlaubt waren.
Vermutlich noch andere Stellen, die ich noch nicht kenne (achja, was ist mit Filefunktion (open() usw.) bezgl. der Pfad/Filenamen mit Encoding? Irgendwas automatisch?)).
Gute Frage, siehe PEP 277. Seit Python 2.3 kann man auf nahezu allen Systemen Unicode-Dateinamen übergeben (an nahezu alle Funktionen - manche wurden vergessen). Dabei wird 1. Unter Win32 das Unicode-API verwendet, also erfolgt gar keine Konvertierung. Das bedeutet wiederum, dass a) unter NT+ (W2k, WXP, W2k3) die Dateien als Unicode-Folge auf dem NTFS abgelegt werden, und b) unter W9x die Namen in CP_ACP konvertiert werden (vom Betriebssystem) Damit kann man im Ergebnis unter NT+ beliebige Unicode-Dateinamen verwenden; unter W9x nur die, die in CP_ACP ("mbcs") unterstützt sind. 2. auf allen anderen Systemen der Dateiname mittels sys.getfilesystemencoding() kodiert. Dieses ergibt sich a) unter Max OS X als "UTF-8" b) unter Systemen, die nl_langinfo(CODESET) unterstützen, entsprechend der locale des Nutzers, und c) auf allen anderen Systemen aus dem system default encoding In Python 2.2 war das etwas anders: Unter Win32 war das file system encoding immer "mbcs" (man hatte also nur 1b), und sonst war es immer system default encoding (also 2c); neu in 2.3 sind also 1a), 2a) und 2b).
Mein Wunsch wäre, eine Liste mit allen diesen Ausnahmen. Das wäre bestimmt sehr hilfreich. Wo genau wird was wegen Rückwärtskompatibel gemacht?
Wie gesagt: Das sind keine Ausnahmen. Ich könnte Deine Frage jetzt so interpretieren als: "Welche API-Funktionen verarbeiten Unicode-Strings, und welche geben Unicode-Strings zurück?" Das würde allerdings eine ziemlich lange Liste werden...
Die Tkinter-Eigenheit führt zB auch in IDLE zu Bugs. Wenn Unicode doch so klar und "durchsichtig" ist, warum passieren dann sogar den Entwicklern der Sprache solche Fehler?
Aus zwei Gründen: Zum einen, weil man in Python immer testen muss, und IDLE offenbar zuwenig getestet wurde (in dieser Frage), zum anderen, weil es historischer Code ist, der früher intern nur Bytestrings verwendet hat, und nun intern Unicode-Strings verwenden sollte, das aber nicht einheitlich macht. Andere Aspekte sind einfach keine Bugs: Das man beispielsweise im interaktiven Modus von IDLE keine Umlaute eingeben darf, ist kein IDLE-Bug. Vielmehr ist nicht klar, was die Umlaute an der Stelle bedeuten sollen, deshalb sind sie nicht erlaubt. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

--On Samstag, 27. Dezember 2003 12:39 Uhr +0100 kgm <km-news3@onlinehome.de> wrote:
Hallo!
ich glaube wirklich, ein gutes Kapitel zum Thema Unicode wäre sehr hilfreich (und da sind schon mehrere Seiten vonnöten!). Das Thema hat nämlich viele Aspekte. Hier in der Mailingliste gab es dazu schon mehrfach Diskussionen. Gerade sehe ich auch einen unvollständigen Thread "Alptraum Unicode".
Die Python-Unicde-Implementierung ist meiner Meinung nach mindestens "undurchsichtig". Ich gehe da aber lieber nicht weiter drauf ein, damit habe ich mich schon "unbeliebt" gemacht. Die vielen alten Diskussionen kann man in dieser Liste ja nachlesen.
Was soll an der Unicode Implementierung von Python undurchsichtig sein? Unwissenheit/Nichtverständnis hat nichts mit Undurchsichtigkeit zu tun. Wie Martin bereits erläutert hat gibt es ein durchgänges und schlüssiges Konzept zur Behandlung von Unicode in Python. -aj _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (7)
-
Andreas Jung
-
Georg Mischler
-
Kai Weber
-
kgm
-
Martin v. Loewis
-
Michael Weigend
-
Olaf 'Ruebezahl' Radicke