Buch "Objektorientierte Programmierung mit Python" Verlag mitp
Hallo, habe mir das Buch "blind" im Versandhandel bestellt. Besonders das "Objektorientiert" im Titel klang vielversprechend. Autor ist Michael Weigend. Von Ihm ist auch schon Python GE-PACKT aus dem gleichen Verlag. Aus Zeitgründn habe ich das Buch bisher nur angelesen und mal "querbeet" durchgesehen. Die folgenden Aussagen bitte unter diesen Gesichtspunkt betrachten. 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. 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. 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. 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. Obwohl schon Pyton V2.3 verwendet wird, werden neue Python Funktionen - wie zB Generatoren - nicht behandelt. 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. -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
Hallo,
habe mir das Buch "blind" im Versandhandel bestellt. Besonders das "Objektorientiert" im Titel klang vielversprechend. Autor ist Michael Weigend. Von Ihm ist auch schon Python GE-PACKT aus dem gleichen Verlag. [...] 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.
Kann ich gut verstehen - sowas habe ich auch schon im Nutshell Buch vermißt. Thomas _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi, das war eins der wenigen Pythonbücher, die ich wieder zurückgestellt habe. Der Titel war vielversprechend, der Inhalt hielt nicht das, was versprochen wurde - Objektorientierte Programmierung mit Python. Gerhard ----------- Thomas Heller wrote:
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
Hallo,
habe mir das Buch "blind" im Versandhandel bestellt. Besonders das "Objektorientiert" im Titel klang vielversprechend. Autor ist Michael Weigend. Von Ihm ist auch schon Python GE-PACKT aus dem gleichen Verlag.
[...]
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.
Kann ich gut verstehen - sowas habe ich auch schon im Nutshell Buch vermißt.
Thomas
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
-- ------------------------------------------------------ skequell ------ Gerhard Quell Software & Knowledge Engineering Schützenweg 3 eMail: gquell@skequell.de Fon: 0731-26400651 89275 Elchingen web : http://www.skequell.de Fax: 0731-26400652 ---Aus Sicherheitsgründen: bitte keine Word-, Excel-Dateianhänge ----- _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
Der Titel war vielversprechend, der Inhalt hielt nicht das, was versprochen wurde - Objektorientierte Programmierung mit Python.
bzgl Objektorientierung verspricht der Titel mehr, als der Inhalt hält. D.h. aber nicht, das ich das Buch für schlecht halte. Wenn man es zB Einführung in Python und Tkinter - oder so ähnlich - genannt hätte, würden Titel und Inhalt besser passen. Wer also sowas in der Richtung noch sucht, sollte es sich durchaus mal anschauen. Der Autor schreibt sachlich und durchaus kompetent und als Einstieg in die Objektorientierung scheint es auch geeignet zu sein. -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Klaus-G. Meyer schrieb:
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!
vielleicht weil man sich dabei leicht aufs Glatteis begeben kann?
Warum das so ist, weiß ich nicht, aber gerade über Unicode hätte ich mir
Zuviele Probleme und Ungereimtheiten?
ein ausführliches Kapitel gewünscht.
Zu diesem Thema würde ich mir am besten ein ganzes Buch wünschen. Vielleicht mit folgendem Inhalt: # Python und Tkinter # Unicode # Wie geht man mit Sonderzeichen um # Wie internationalisiert man ein Programm Gruß Mike _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
Warum das so ist, weiß ich nicht, aber gerade über Unicode hätte ich mir
Zuviele Probleme und Ungereimtheiten?
Und fehlende gute Anwender-Doku? Keine Ahnung, ob das beim Autor der Grund war, aber die Unicode-Implementierung in Python ist meiner Meinung nach sehr unglücklich. Ich war schon manchmal nahe dran, Python deshalb in die Tonne zu treten - um es drastisch zu sagen. Ich habe mein Unbehagen mit Pythons Unicode hier ja schon im Sommer verbreitet. Leider stößt man aber damit eher auf taube Ohren. Deshalb mache ich mir jetzt auch nicht die Mühe, die kritischen Punkte aufzuzählen. Die Probleme müssen wohl erst noch länger hochkochen, es wäre aber schade, wenn Python letzlich dadurch Schaden nimmt ("Unicode in Python ist sooo kompliziert usw"). Trotzdem noch folgende Anmerkungen: Auch die Python-Gurus haben Ihre liebe Mühe mit Unicode, das beste Beispiel ist Idle (an dem laut http://idlefork.sourceforge.net/tasks.php zB auch Guido mitwirkt (der die Ur-Versionen sowieso geschrieben hat)). Man starte idle.py (nicht idle.pyw) und jetzt öffne/lese/schreibe man Dateien, die im Pfadname oder Namen Umlaute haben und dann bewundere man die Exception, die Idle wirft! Ich will die Idle-Leute nicht anprangern! Idle dient mir nur als Beispiel dafür, das was nicht stimmt in Pythons Unicode-Wunderland! Soviel ich weiß lesen hier doch auch einige in der Python-Entwicklung aktive User mit. Vielleicht denken die nochmal unvoreingenommen über das Thema nach bzw. diskutieren es nochmals. Mit Latin-1 statt USASCII hätte man immerhin 20 Ländern (statt nur USA) geholfen, darunter bedeutende Sprachen: http://de.wikipedia.org/wiki/ISO_8859-1 -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Klaus-G. Meyer schrieb:
Mit Latin-1 statt USASCII hätte man immerhin 20 Ländern (statt nur USA) geholfen, darunter bedeutende Sprachen: http://de.wikipedia.org/wiki/ISO_8859-1
Man wollte, soweit ich weiß, den kleinsten gemeinsamen Nenner treffen und der ist nun mal leider ASCII. Daher wird in der Datei site.py (bitte suchen) ja das locale encoding abgeschaltet. if hasattr(sys,"setdefaultencoding"): del sys.setdefaultencoding Ja mit der ganzen Geschichte (Sonderzeichen und so weiter) bin ich auch unzufrieden. Soweit ich es verstehe gibt es einmal die Python Seite und dann die ganze GUI Seite (Tkinter (TK/Tcl), usw.) und das Miteinander ist das Problem. Gruß Mike PS. Alptraum letzte Nacht: "ordinal not in range" _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Mike Abel wrote:
Klaus-G. Meyer schrieb:
Mit Latin-1 statt USASCII hätte man immerhin 20 Ländern (statt nur USA) geholfen, darunter bedeutende Sprachen: http://de.wikipedia.org/wiki/ISO_8859-1
Wenn du diese Seite wirklich gelesen haettest, dann wuerdest du stattdessen wohl eher ISO-8859-15 (Latin-9) empfehlen...
Man wollte, soweit ich weiß, den kleinsten gemeinsamen Nenner treffen und der ist nun mal leider ASCII.
Das ist auch der einzige vernuenftige Weg. Ich denke, dass mit ASCII ca. 50-100 Sprachen abgedeckt werden, vielleicht auch mehr. Die Anzahl Menschen, welche diese Sprachen sprechen, duerfte deutlich groesser sein als die Bevoelkerung von Westeuropa. Gleichzeitig ist ASCII mit dem Anfang von Unicode identisch. ISO-8859-15 wuerde da gerade mal gut 20 Sprachen hinzufuegen, aber die existierende Kompatibiltaet mit Unicode beseitigen. Damit wuerde fuer die uebrigen mehreren tausend Sprachen der Zugang nicht erleichtert, sondern erschwert.
Ja mit der ganzen Geschichte (Sonderzeichen und so weiter) bin ich auch unzufrieden.
Mir scheint, bei der ganzen Diskussion wird gerne auf dem Ueberbringer der Botschaft (Python/Unicode) herumgepruegelt. Tatsache ist, dass die Unterstuetzung aller Sprachen und Schriften in einer Programmiersprache und einem GUI-Toolkit ein nichttriviales Problem darstellt. Jedenfalls solange man nicht die Verwendung von Fonts mit 30'000 verschiedenen Schriftzeichen in Erwaegung ziehen will. Ich habe bisher noch keine Loesung gesehen, welche dieses Problem so elegant und geradlinig angeht wie die Kombination von Unicode und Python. Aber ein Buch, welches das Thema und seine effiziente Handhabung grundlegend und umfassend beschreibt, vermisse ich natuerlich auch. -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
Georg Mischler schrieb:
ISO-8859-15 wuerde da gerade mal gut 20 Sprachen hinzufuegen, aber die existierende Kompatibiltaet mit Unicode beseitigen.
Wie meinst Du das?
Mir scheint, bei der ganzen Diskussion wird gerne auf dem Ueberbringer der Botschaft (Python/Unicode) herumgepruegelt.
Herumgeprügelt wäre das falsche Wort. Aber die Wahrheit tut manchmal weh. :-)) Gruß Mike _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
geholfen, darunter bedeutende Sprachen: http://de.wikipedia.org/wiki/ISO_8859-1
Wenn du diese Seite wirklich gelesen haettest, dann wuerdest du stattdessen wohl eher ISO-8859-15 (Latin-9) empfehlen...
wie wäre den mit einer kleinen Entschuldigung für die Unterstellung?
ISO-8859-15 wuerde da gerade mal gut 20 Sprachen hinzufuegen, aber die existierende Kompatibiltaet mit Unicode beseitigen.
Eben, und deshalb natürlich Latin-1, weil: Der häufig benutzte Latin-1-Zeichensatz ist identisch mit den ersten 256 Zeichen des Unicode-Zeichensatzes.
Ich denke, dass mit ASCII ca. 50-100 Sprachen abgedeckt werden, Quelle?
sprechen, duerfte deutlich groesser sein als die Bevoelkerung von Westeuropa. Gleichzeitig ist ASCII mit dem Anfang von Unicode identisch. Und Latin-1 wäre mit den ersten 256 Zeichen gleich. Und wie Du auf der Wikipeda-Seite gesehen hättest, hätte das, nur als ein Beispiel, Spanisch hinzugefügt. Spanisch wird nicht nur in Europa gesprochen. Spanisch wird als Muttersprache von ca. 300 Mill. Menschen weltweit gesprochen (Quelle: Encarta).
Aber ein Buch, welches das Thema und seine effiziente Handhabung grundlegend und umfassend beschreibt, vermisse ich natuerlich auch.
Zumindest da sind wir uns einig. -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Klaus-G. Meyer wrote:
ISO-8859-15 wuerde da gerade mal gut 20 Sprachen hinzufuegen, aber die existierende Kompatibiltaet mit Unicode beseitigen.
Eben, und deshalb natürlich Latin-1, weil:
Der häufig benutzte Latin-1-Zeichensatz ist identisch mit den ersten 256 Zeichen des Unicode-Zeichensatzes.
Das ist technisch gesehen zwar korrekt, kann aber die praxisbezogenen Maengel von ISO-8859-1 nicht aufwiegen. One Euro-Zeichen ist der Zeichensatz inzwischen schlicht obsolet, oder bestenfalls von sehr fragwuerdigem Nutzen.
Ich denke, dass mit ASCII ca. 50-100 Sprachen abgedeckt werden, Quelle?
In den Laendern Afrikas und SE-Asiens, welche von England oder den Niederlanden kolonialisiert waren, wurde fuer die lokalen Sprachen normalerweise eine ASCII-basierte Schreibweise eingefuehrt. Die prominentesten Beispiele sind Indonesisch und Malay. Spontan fallen mir noch ein paar andere Beispiele ein, aber eine vollstaendige Liste habe ich nicht gerade rumliegen.
Und wie Du auf der Wikipeda-Seite gesehen hättest, hätte das, nur als ein Beispiel, Spanisch hinzugefügt. Spanisch wird nicht nur in Europa gesprochen. Spanisch wird als Muttersprache von ca. 300 Mill. Menschen weltweit gesprochen (Quelle: Encarta).
D.h. dass ASCII alleine ganz grob 5% der Weltbevoelkerung abdeckt, und ISO-8859-x vielleicht 10%. Beides ist nur ein Tropfen auf dem heissen Stein. Ohne Unicode laesst sich das Problem nun mal beim besten Willen nicht loesen. Ein default von ISO-8859-x würde den Entwicklern (vorallem in Europa) nur ein falsches Gefuehl der Sicherheit vorspiegeln. -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, On Sat, Nov 29, 2003 at 04:56:02PM +0100, Klaus-G. Meyer wrote:
Der h)Bäufig benutzte Latin-1-Zeichensatz ist identisch mit den ersten 256 Zeichen des Unicode-Zeichensatzes.
Wie bitte? Latin-1 ist ein 8-bit-Zeichensatz, Unicode (zumindest als ISO 10646, bzw. UCS-4) ist 32bit. Wie sollen die gleich sein? Ansonsten gibt es Unicode noch als UCS-2, das ist 16bit. Die einzige 8-bit Variante ist AFAIK UTF-8, und das ist nun gerade *nicht* identisch mit ISO 8859-1 oder -15. UTF-8 verwendet naemlich shift-bytes, ein Konzept, das ISO8859 nicht kennt. Kann sein, dass es noch 16bit UTF Versionen gibt, das kann ich gerade nicht nachgucken. Cheerio, Jan Wender -- Jan Wender science + computing ag scVENUS Software Development Phone +49 7071 9457257 The ultimate laziness is not using Perl. That saves you so much work you wouldn't believe it if you had never tried it. (Erik Naggum, comp.lang.lisp) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
Der h)Bäufig benutzte Latin-1-Zeichensatz ist identisch mit den ersten 256 Zeichen des Unicode-Zeichensatzes.
Wie bitte? Latin-1 ist ein 8-bit-Zeichensatz, Unicode (zumindest als ISO 10646, bzw. UCS-4) ist 32bit. Wie sollen die gleich sein? Gleiche Kodierungsnummern. Siehe in der offiziellen Unicode-Doku, dort findest Du diesen Hinweis häufiger. http://www.unicode.org/versions/Unicode4.0.0/bookmarks.html
The first 256 codes follow precisely the arrangement of ISO/IEC 8859-1 (Latin 1), of which 7-bit ASCII (ISO/IEC 646 IRV) accounts for the first 128 code positions. usw... -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
Der häufig benutzte Latin-1-Zeichensatz ist identisch mit den ersten 256 Zeichen des Unicode-Zeichensatzes.
Wie bitte? Latin-1 ist ein 8-bit-Zeichensatz, Unicode (zumindest als ISO 10646, bzw. UCS-4) ist 32bit. Wie sollen die gleich sein? Gleiche Kodierungsnummern.
Das erleichtert allerdings überhaupt nichts. Die Konvertierung zwischen Unicode-Strings und Latin-1-Byte-Strings ist in jedem Fall durch einen Algorithmus auszuführen - nur dass der Algorithmus relativ effizient implementiert werden kann. Wäre Latin-9 das system encoding in Python, wäre das aber auch nicht komplizierter, als wenn es Latin-1 wäre. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo,
Wie bitte? Latin-1 ist ein 8-bit-Zeichensatz, Unicode (zumindest als ISO 10646, bzw. UCS-4) ist 32bit. Wie sollen die gleich sein? Ansonsten gibt es Unicode noch als UCS-2, das ist 16bit. Die einzige 8-bit Variante ist AFAIK UTF-8, und das ist nun gerade *nicht* identisch mit ISO 8859-1 oder -15. UTF-8 verwendet naemlich shift-bytes, ein Konzept, das ISO8859 nicht kennt. Kann sein, dass es noch 16bit UTF Versionen gibt, das kann ich gerade nicht nachgucken.
du wirfst da Unicode und die Varianten solche Zeichen zu kodieren gnadenlos durcheinander. Unicode weiß nichts von Bits, sondern ordnet erstmal nur einem Zeichen einen Zahl zu. Zufällig lassen sich all' diese Zahlen im aktuellen Standard mit 32 Bit darstellen. UCS-2, UCS-4, UTF-8 unt UTF-16 sind alles Varianten, diese Zahlen auf verschiedene Arten im Rechner zu kodieren. Das eine hat mit dem anderen aber nichts zu tun. Gruß, Achim _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
ganze GUI Seite (Tkinter (TK/Tcl), usw.) und das Miteinander ist das
machst Du was mit Tkinter? Ich habe leider feststellen müssen, das die Tkinter-Funktionen mal Strings, mal Unicode-Strings zurückgeben (je nachdem, ob zB Umlaute in der Eingabe waren). Jetzt bearbeite ich jeden von Tkinter zurückgegeben String mit der folgenden Mini-Funktion (ist natürlich auf Latin-1 beschränkt). Vielleicht nutzt es Dir ja auch was: def Latin1(ustr): if isinstance(ustr, unicode): return ustr.encode("latin-1") else: return ustr bstring = Latin1(tkinter_rueckgabe) -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
Ich habe leider feststellen müssen, das die Tkinter-Funktionen mal Strings, mal Unicode-Strings zurückgeben (je nachdem, ob zB Umlaute in der Eingabe waren).
Es wäre relativ einfach, Tkinter so zu ändern, dass es immer Unicode-Strings zurückgibt. Aber würde Dir das helfen? Und wäre es rückwärtskompatibel? Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
Es wäre relativ einfach, Tkinter so zu ändern, dass es immer Unicode-Strings zurückgibt. Aber würde Dir das helfen? wenig, man könnte aber pauschal alle Rückgaben durch encode("latin-1") jagen.
Und wäre es rückwärtskompatibel? Da sehe ich wenig Unterschide zur jetzigen Lösung, die mal Strings, aber auch mal Unicode zurückgibt. Das fand ich sogar heimtükisch, da ich es erst ziemlich spät bei einem Test gemerkt habe. :-(
-- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
Es wäre relativ einfach, Tkinter so zu ändern, dass es immer Unicode-Strings zurückgibt. Aber würde Dir das helfen? wenig, man könnte aber pauschal alle Rückgaben durch encode("latin-1") jagen.
Das kann man natürlich im Moment auch schon, auch wenn es für Byte-Strings ein wenig teuer ist.
Und wäre es rückwärtskompatibel? Da sehe ich wenig Unterschide zur jetzigen Lösung, die mal Strings, aber auch mal Unicode zurückgibt. Das fand ich sogar heimtükisch, da ich es erst ziemlich spät bei einem Test gemerkt habe. :-(
Das hat mit Rückwärtskompatibilität allerdings nichts zu tun: Das aktuelle Verhalten ist so seit Python 2.0. Das es so schlecht dokumentiert ist, liegt daran, dass Tkinter insgesamt schlecht dokumentiert ist. Das liegt wiederum daran, dass es soviel Arbeit ist. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
wenig, man könnte aber pauschal alle Rückgaben durch encode("latin-1") jagen.
Das kann man natürlich im Moment auch schon, auch wenn es für Byte-Strings ein wenig teuer ist.
aber nur unter der Randbedingung, das die Byte-Strings von Tkinter nur ASCII enthalten. Ist das sicher? -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
Das kann man natürlich im Moment auch schon, auch wenn es für Byte-Strings ein wenig teuer ist.
aber nur unter der Randbedingung, das die Byte-Strings von Tkinter nur ASCII enthalten. Ist das sicher?
Das ist sicher für alle Funktionen, die in Tcl "strings" zurückgeben. Es gibt in Tcl auch den Datentyp "bytearray" - falls man den in die Hand bekommt, kann er alles mögliche enthalten. Allerdings gibt es m.W. kein Widget, aus dem jemals bytearray herauskommt. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Klaus-G. Meyer, et al.:
aber nur unter der Randbedingung, das die Byte-Strings von Tkinter nur ASCII enthalten. Ist das sicher?
Aehm, mit Verlaub, was hat das alles mit Buechern ueber objektorien- tierte Programmierung in Python zu tun? Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "The whole point of brainwashing, is that those being brainwashed don't know it." (Graham Haley) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Martin, noch eine andere Frage zu Tkinter: Mike Abel und ich haben per Email noch ein paar Tkinter-Dinge besprochen und dabei einen Unterschied zwischen der Win und der Linux-Version bemerkt. Die Funktion tkFileDialog.askdirectory() liefert unter Win einen String, unter Linux aber ein Tcl_Obj!? Ist das ein Bug? Es macht einem zumindest nicht gerade leichter, Scripte zu schreiben, die auf beiden OSen laufen. Gibt es noch andere dieser (bewußten) Unterschiede? Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import Tkinter Tkinter.TkVersion 8.4000000000000004 Tkinter.TclVersion 8.4000000000000004 import tkFileDialog tkFileDialog.askdirectory( title="blah", mustexist=False) 'C:/Programme/Python/Doc' type(tkFileDialog.askdirectory( title="blah", mustexist=False)) <type 'str'>
Python 2.3 (#2, Aug 31 2003, 17:27:29) [GCC 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import Tkinter Tkinter.TkVersion 8.4000000000000004 Tkinter.TclVersion 8.4000000000000004 import tkFileDialog tkFileDialog.askdirectory(title="nn") <path object at 0x081d09b8> type(tkFileDialog.askdirectory(title="n")) <type '_tkinter.Tcl_Obj'>
-- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
Mike Abel und ich haben per Email noch ein paar Tkinter-Dinge besprochen und dabei einen Unterschied zwischen der Win und der Linux-Version bemerkt. Die Funktion tkFileDialog.askdirectory() liefert unter Win einen String, unter Linux aber ein Tcl_Obj!?
Ist das ein Bug?
Ja, aber u.U. ein Bug in Tk.
Es macht einem zumindest nicht gerade leichter, Scripte zu schreiben, die auf beiden OSen laufen. Gibt es noch andere dieser (bewußten) Unterschiede?
Das ist kein bewusster Unterschied: der Code ist der identisch selbe auf beiden Systemen. Warum da mal ein path-Objekt und mal ein String zurückkommt, weiß ich nicht. Man kann das relativ einfach umgehen, indem man unicode(tkFileDialog.askdirectory( title="blah", mustexist=False)) schreibt. Es ist allerdings ein Bug, dass man dieses path object nicht an open() übergeben kann. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
[Klaus-G. Meyer Sat, Nov 29, 2003 at 02:51:52PM +0100]
Hi,
Warum das so ist, weiß ich nicht, aber gerade über Unicode hätte ich mir
Zuviele Probleme und Ungereimtheiten?
Und fehlende gute Anwender-Doku?
Keine Ahnung, ob das beim Autor der Grund war, aber die Unicode-Implementierung in Python ist meiner Meinung nach sehr unglücklich. Ich war schon manchmal nahe dran, Python deshalb in die Tonne zu treten - um es drastisch zu sagen.
Hmmm. merkwuerdig. Ich hatte etwas Anfangsprobleme, aber nachdem mir das Grundkonzept erklaert wurde, war die Python-API straight-forward und konsistent. Mittlerweile ziehe ich bei meinen Applikationen meist klare Grenzen: auf der einen Seite nur unicode, auf der anderen nur bytestrings und encodings. Dadurch stellt sich notwendigerweise an allen Eingangs- und Ausgangspunkten einer API die Frage, welches Encoding bytestrings jeweils haben. Um die Beantwortung dieser Frage kommt man IMO durch andere Defaults letztlich nicht herum.
Ich habe mein Unbehagen mit Pythons Unicode hier ja schon im Sommer verbreitet. Leider stößt man aber damit eher auf taube Ohren. Deshalb mache ich mir jetzt auch nicht die Mühe, die kritischen Punkte aufzuzählen. Die Probleme müssen wohl erst noch länger hochkochen, es wäre aber schade, wenn Python letzlich dadurch Schaden nimmt ("Unicode in Python ist sooo kompliziert usw").
Kennst Du eine Programmiersprache, wo das alles viel besser und einfacher ist? Wenn ja, inwiefern? (bin einfach nur interessiert)
Soviel ich weiß lesen hier doch auch einige in der Python-Entwicklung aktive User mit. Vielleicht denken die nochmal unvoreingenommen über das Thema nach bzw. diskutieren es nochmals.
Mit Latin-1 statt USASCII hätte man immerhin 20 Ländern (statt nur USA) geholfen, darunter bedeutende Sprachen: http://de.wikipedia.org/wiki/ISO_8859-1
Siehst du noch ein anderes Problem, als das default-encoding? gruss, holger _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
konsistent. Mittlerweile ziehe ich bei meinen Applikationen meist klare Grenzen: auf der einen Seite nur unicode, auf der anderen nur
schön, für klare Grenzen brauchst Du auch klare Doku. Bei jeder Funktion (die Strings als in oder out hat), müßte beschrieben sein, wie sich sich bei Unicode verhält, wwelchen Stringtype sie zurückgibt usw. Das scheint mir, ganz besonders bei Tkinter, zu fehlen?
Kennst Du eine Programmiersprache, wo das alles viel besser und einfacher ist? Wenn ja, inwiefern? (bin einfach nur interessiert) Sorry, da kann ich nicht helfen. Ich programmieren nur selten was mit Zeichensätzen ;-) Und wenn, dann eben meistens mit Python.
Siehst du noch ein anderes Problem, als das default-encoding? Mangelnde allgemeine Doku, mangelnde Doku der Fkt. bzgl Unicode-Verhalten und der ganzen Thematik. Das hier gefällt mir auch nicht so besonders: http://www.python.org/peps/pep-0263.html. Ist natürlich eine Folge des ASCII-Encodings. Without such an encoding declaration, the default encoding used is 7-bit ASCII. Executing or importing modules that contain string literals with 8-bit characters and have no encoding declaration will result in a DeprecationWarning being signalled by Python 2.3; in 2.4 this will be a syntax error.
Damit dürfte so mancher Script spätestens mit 2.4 auch nicht mehr laufen, nur weil man mal einen Umlaut verwendet hatte. -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Klaus-G. Meyer schrieb:
http://www.python.org/peps/pep-0263.html. Ist natürlich eine Folge des ASCII-Encodings. Without such an encoding declaration, the default encoding used is 7-bit ASCII. Executing or importing modules that contain string literals with 8-bit characters and have no encoding declaration will result in a DeprecationWarning being signalled by Python 2.3; in 2.4 this will be a syntax error.
Habe den PEP vorliegen aber noch nicht genau analysiert. Doch was Du gerade schreibst, klingt doch logisch, und löst ein Teil der Probleme indem man das encoding vorgibt welches im Modul etc. verwendet wird. Damit hat das raten ein Ende; zumindest teilweise.
Damit dürfte so mancher Script spätestens mit 2.4 auch nicht mehr laufen, nur weil man mal einen Umlaut verwendet hatte.
Eine Zeile mehr und schon sollte das Script wieder laufen. Gruß Mike _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
Damit dürfte so mancher Script spätestens mit 2.4 auch nicht mehr laufen, nur weil man mal einen Umlaut verwendet hatte.
Nein, auch in 2.4 werden sie alle weiter funktionieren. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Martin,
Damit dürfte so mancher Script spätestens mit 2.4 auch nicht mehr laufen, nur weil man mal einen Umlaut verwendet hatte.
Nein, auch in 2.4 werden sie alle weiter funktionieren.
In der Python-Hilfe steht halt:
importing modules that contain string literals with 8-bit characters and have no encoding declaration will result in a DeprecationWarning being signalled by Python 2.3; in 2.4 this will be a syntax error.
Wie kann den ein Script mit einem Syntax Error laufen? Oder ist da die Hilfe falsch? -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Klaus-G. Meyer schrieb:
Hi Martin,
Damit dürfte so mancher Script spätestens mit 2.4 auch nicht mehr laufen, nur weil man mal einen Umlaut verwendet hatte.
Nein, auch in 2.4 werden sie alle weiter funktionieren.
In der Python-Hilfe steht halt:
importing modules that contain string literals with 8-bit characters and have no encoding declaration will result in a DeprecationWarning being signalled by Python 2.3; in 2.4 this will be a syntax error.
Wie kann den ein Script mit einem Syntax Error laufen? Oder ist da die Hilfe falsch?
Das ist wohl eher so zu verstehen daß unter 2.3 eine Warnung erscheint (habe ich bei meinen Sonderzeichenexperimenten am Wochenende erlebt), aber in Version 2.4 dann ein Syntaxfehler vorliegt. Damit habe ich kein Problem; Python ist in diesem Punkt einfach nur nett. Gruß Mike _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Mike Abel <F10@gmx.de> writes:
Das ist wohl eher so zu verstehen da_ unter 2.3 eine Warnung erscheint (habe ich bei meinen Sonderzeichenexperimenten am Wochenende erlebt), aber in Version 2.4 dann ein Syntaxfehler vorliegt.
Ich glaube, statt "Version 2.4" sollte es einfach "später" heißen. Das kann Version 2.4, 2.5, oder 3.0 sein. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
importing modules that contain string literals with 8-bit characters and have no encoding declaration will result in a DeprecationWarning being signalled by Python 2.3; in 2.4 this will be a syntax error.
Wie kann den ein Script mit einem Syntax Error laufen? Oder ist da die Hilfe falsch?
Die Hilfe ist falsch. Sie kann unmöglich wissen, was in Python 2.4 sein wird - Python 2.4 ist noch nicht fertig. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Klaus-G. Meyer" <km-news3@onlinehome.de> writes:
Soviel ich weiß lesen hier doch auch einige in der Python-Entwicklung aktive User mit. Vielleicht denken die nochmal unvoreingenommen über das Thema nach bzw. diskutieren es nochmals.
Ich glaube nicht, dass diskutieren viel hilft. Wenn IDLE keine Dateien mit Umlaut im Namen öffnen kann, ist das ein Bug. Diesen Bug muss irgend jemand als Bug melden, und irgend jemand anderes muss ihn beheben. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (10)
-
Achim Domma (Procoders) -
Dinu Gherman -
Georg Mischler -
gerhard quell -
holger krekel -
Jan Wender -
Klaus-G. Meyer -
martin＠v.loewis.de -
Mike Abel -
Thomas Heller