Re: AW: [mailinglist] Re: [Python-de] socket und umlaute
Am Don, 2003-11-20 um 15.38 schrieb Uwe Schmitt:
Bei Dir liegt "commant" wohl als Unicode-String vor. Dann kann das ja nicht funktionieren. Die zweite Fehlermeldung geht damit konform.
O.K. wenn mein "commant" Unicode ist und Socket Unicode unterstützt warum knackt er dann ab bei der zweiten Variante? self.my_socket.send(commant) mit
Richtig:
self.my_socket.send(commant.encode("utf-8"))
Geht es. Aber dann habe ich den Ärger auf der anderen Seite(der Verbindung). Da kommt dann an den Stellen wo die Umlaute waren nur Kauderwelsch. Das ändert sich auch nicht wenn ich beim Empfänger ein commant.encode("Latin-1") mache. -- =================================================== "Meine Meinung steht fest. Bitte verwirren sie mich nicht mit Tatsachen!" Unbekannt. =================================================== _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Olaf 'Ruebezahl' Radicke wrote:
Am Don, 2003-11-20 um 15.38 schrieb Uwe Schmitt:
Bei Dir liegt "commant" wohl als Unicode-String vor. Dann kann das ja nicht funktionieren. Die zweite Fehlermeldung geht damit konform.
O.K. wenn mein "commant" Unicode ist und Socket Unicode unterstützt warum knackt er dann ab bei der zweiten Variante?
self.my_socket.send(commant)
Weil socket nicht "unicode unterstützt". Auf Ebene des Sockets gibt es nur "bytes". Und "bytes" werden in Python durch normale Text-Strings repraesentiert.
mit
Richtig:
self.my_socket.send(commant.encode("utf-8"))
Geht es.
In diesem Fall uebertraegt der Socket Text, welcher im UTF-8 Format kodierte Unicode-Daten enthaelt.
Aber dann habe ich den Ärger auf der anderen Seite(der Verbindung). Da kommt dann an den Stellen wo die Umlaute waren nur Kauderwelsch.
Nicht Kauderwelsch, sondern die UTF-8 Kodierung. Das ist so auch korrekt, denn die hast du ja selber schon im XML-Header explizit deklariert.
Das ändert sich auch nicht wenn ich beim Empfänger ein commant.encode("Latin-1") mache.
Natuerlich kannst du einen UTF-8 kodierten Text nicht direkt nochmal als Latin-1 kodieren. Den musst du zuerst wieder in das Python-interne Unicode-Format *dekodieren*. Erst danach kannst du ihn sinnvoll weiterverarbeiten, und bei Bedarf auch wieder in eine andere Text-Kodierung wie Latin-1 umwandeln. -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 <schorsch@schorsch.com> writes:
Aber dann habe ich den Ärger auf der anderen Seite(der Verbindung). Da kommt dann an den Stellen wo die Umlaute waren nur Kauderwelsch.
Nicht Kauderwelsch, sondern die UTF-8 Kodierung. Das ist so auch korrekt, denn die hast du ja selber schon im XML-Header explizit deklariert.
Tatsächlich hatte er im XML-Header "ISO-8859-1" deklariert - also sollte er das Dokument auch als ISO-8859-1 kodieren. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Moin, Olaf 'Ruebezahl' Radicke wrote:
... mit
Richtig:
self.my_socket.send(commant.encode("utf-8"))
Geht es. Aber dann habe ich den Ärger auf der anderen Seite(der Verbindung). Da kommt dann an den Stellen wo die Umlaute waren nur Kauderwelsch. Das ändert sich auch nicht wenn ich beim Empfänger ein commant.encode("Latin-1") mache.
(alles ohne Zugriff auf Python, also Vorsicht :-)) auf der Empfaengerseite kommt ein "Strom" von Zeichen mit UTF-8-kodiertem Unicode an. Den kannst Du z.B. mit wiederUnicode = unicode(zeichenUtf8, "UTF-8") in einen Unicode-String verwandeln. Und dann z.B. mit wiederUnicode.encode("latin-1") auch wieder ausgeben.
...
Unicode-geschaedigte Gruesse Uwe _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Also erstmal Danke für eure Geduld! Und ich fasse noch mal das Ergebnis für mich zusammen: Meinen Unicode-String "command" wandel ich mit command.encode("Latin-1") um weil ich mein XML-String sowieso als ISO-8859-1 kodieren und schicke das Ergebnis über mein Socket. Was ich da jetzt rüber geschickt habe, kann ich jetzt normal mit print ausgeben lassen. Das PostgreSQL-Modul pg schluckt das so aber auch noch nicht, (ob wohl es eigentlich kein Unicode mehr sein kann) so das ich hier auch noch mal ein command.encode("Latin-1") verwenden muss. - Aber dann geht das und in in meiner DB stehen dann auch tatsächlich Umlaute. Python ist nach wie vor meine beliebteste Programmiersprache, aber die fehlende Typensicherheit halte ich für ein Mangel. Erstens, weil kein überladen von Methoden möglich ist. Zweitens, weil Python schneller sein könnte, wenn zwischen Typen unterschieden würde. Drittens, wegen obigen Problem. Viertens wegen den Problemen die auftreten können wie in dem Beispiel-Code unten. str_vier = "4" int_vier = 4 print "vier und vier sind..." if str_vier == int_vier: print "gleich" elif str_vier != int_vier: print "ungleich" else: print "nichts von beiden" print "vier plus vier sind: ",(str_vier + str_vier) print "...aber auch: ", (int_vier + int_vier) zwischenspeicher = str_vier str_vier = int_vier int_vier = zwischenspeicher print "ist ", int(str_vier), " jetzt ein int oder str?" print "ist ", str(int_vier), " jetzt ein int oder str? MfG Olaf Radicke -- =================================================== "Meine Meinung steht fest. Bitte verwirren sie mich nicht mit Tatsachen!" Unbekannt. =================================================== _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
--On Freitag, 21. November 2003 17:47 Uhr +0100 Olaf 'Ruebezahl' Radicke <olaf_rad@gmx.de> wrote:
Python ist nach wie vor meine beliebteste Programmiersprache, aber die fehlende Typensicherheit halte ich für ein Mangel.
Wenn Du Typisierung brauchst, dann schau Dir mal die Implementierung der pre- und postconditions (die man von Eiffel her kennt) für Python an. Die Frage von Typsicherheit und Überladen ist auch eine Frage des eigenen Programmierstils. Ich habs bisher in meinen 10 Python Jahren nicht sonderlich vermisst. -aj _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Olaf, Am 21 Nov 2003 17:47:05 +0100 Schrieb Olaf 'Ruebezahl' Radicke <olaf_rad@gmx.de>:
... zwischenspeicher = str_vier str_vier = int_vier int_vier = zwischenspeicher ... das ist aber kein Python.
str_vier, int_vier = int_vier, str_vier das ist Python! ;-) Gruß Fritz _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
in dem Beispiel-Code unten.
gibt zu, Du programmierst sonst in Perl und erwartest von Python, es sei ähnlich wie Perl! ;-) Aber ehrlich, Du solltest unbedingt noch mal etwas in der Python Doku schmöckern, Python ist (zum Glück) anders als Perl. Liest doch mal das Tutorial, da findest Du viele Grund-Aussagen, zB Kapitel 5.7 "Comparing Sequences and Other Types", dann wird Dir zB klar, warum Deine Vergleiche zwischen verschiedenen Typen nicht nach Deinen Erwartungen funktionieren.
print "vier plus vier sind: ",(str_vier + str_vier)
Sowas geht zB in Perl, weil Perl das + für die Addition hernimmt, aber den . für Stringverknüpfung. Da also über den Operator der Typ zwangsläufig vorgeschrieben ist, konvertiert Perl automagisch Strings in Zahlen und addiert dann. Das ganze läuft bei Perl unter dem Stichwort "Kontext". Mit dem + hast Du gesagt "nummerischer Kontext", also kann es nur eine Addition sein. Mit dem . sagst Du "String Kontext" und deshalb erfolgt dann eine Umwandlung des Int in einen String. Als Folge dieses Konzeptes benötigt Perl auch mehr Operatoren, zB eq, lt, gt usw. für Strings. In Python ist der Operator + dagegen überladen und seine Funktion hängt von den Daten ab, bei Zahlen "Addition", bei Strings "Verkettung". Wenn Du zwei gemischte Daten zB ein Int und ein String an das + übergibst, gibt es eine Fehlermeldung. Was soll Python auch machen? Der Int schreit "Ich bin eine Zahl, addiere mich!" und der String "Ich bin ein String, verkette mich!". Sollte Python das auch automagisch machen? Aber wie - den String in eine Zahl wandeln und addieren, oder die Zahl in einen String wandeln und verketten? Da das nicht eindeutig geht, muss das der Programmierer entscheiden und zB den String selber in eine Zahl wandeln: int("4") (siehe dazu auch mal hier, Regel 2 ;-) http://www.python.org/doc/Humor.html#zen) Und hier noch ein wichtiger Info-Link zu Deinen Beispielen: http://starship.python.net/crew/mwh/hacks/objectthink.html#mwh -- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Alles schön und gut. Eine so hohe Abstraktion mag seine Vorteile haben. Aber es währe noch schöner wenn ich die *Möglichkeit* hätte, Typen so zu deklarieren das ich z.B. nicht mehr einfach eine Variable mal als str mal int benutzen kann. Weil wenn ich ein ziemlich langen verworrenen Code habe, wie soll ich da raus finden, ob ich jetzt ein int oder ein str vor mir hab? Selbst wenn ich im Code nach einer Zuweisung suche kann ich Pech haben und in irgend einer unterfunktion wird da stillschweigend aus ein int ein str gemacht. Eh ich den Fehler gefunden habe, können Tage vergehen. Ich könnte mir eine Klasse bzw. Typ "StaticTyp" Vorstellen: int_vier = StaticTyp(int, "4") str_vier = StaticTyp(str, "4") try: if int_vier == str_vier: print "kein Fehler" except StaticTypError, par: print "So ja nicht: ", par PS: Was meine Programmiererfahrung betrifft. In den letzten ca. 2 Jahren habe ich mich mit C, C++ und Perl beschäftigt. Perl war meine erste Sprache, die ich aber sehr schnell verwarf, weil sich Python wesentlich leichter debggen lässt. Für C und C++ sind meine Projekte zu klein (auch personell) als das der Aufwand noch in Relation zum Nutzen stände. Olaf -- =================================================== "Meine Meinung steht fest. Bitte verwirren sie mich nicht mit Tatsachen!" Unbekannt. =================================================== _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
On Fr November 21 2003 17:47, Olaf 'Ruebezahl' Radicke wrote:
str_vier = "4" int_vier = 4
print "vier und vier sind..." if str_vier == int_vier: print "gleich" elif str_vier != int_vier: print "ungleich" else: print "nichts von beiden"
Nur ne kleine Idee. :-) str_vier = "4" int_vier = 4 if type(str_vier) != type(int_vier): print "nichts von beiden" elif str_vier == int_vier: print "gleich" else: print "ungleich" -Falk _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
On Fri, 2003-11-21 23:32:07 +0100, Falk Friedrich wrote:
Nur ne kleine Idee. :-)
str_vier = "4" int_vier = 4 if type(str_vier) != type(int_vier): print "nichts von beiden"
Das ist auch so eine Sache. Zum einen sind "4" und 4 - nach Pythons nachvollziehbarer Auffassung - ungleich. Zum anderen haben 4 und 4.0 nicht den gleichen Typ, können aber mit einiger Berechtigung als gleich angesehen werden (werden sie tatsächlich auch von Python). Das angemessenste ist meiner Meinung nach, sich an Pythons "Philosophie" zu gewöhnen. Wenn man sich der Regeln bewusst ist, geht das alles "erstaunlich" problemlos und leicht von der Hand. Viele Grüße Stefan _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Olaf 'Ruebezahl' Radicke" <olaf_rad@gmx.de> writes:
Meinen Unicode-String "command" wandel ich mit command.encode("Latin-1") um weil ich mein XML-String sowieso als ISO-8859-1 kodieren und schicke das Ergebnis über mein Socket. [...] Python ist nach wie vor meine beliebteste Programmiersprache, aber die fehlende Typensicherheit halte ich für ein Mangel.
Die Typisierung ist vielleicht problematisch - dieses Beispiel ist aber ganz bestimmt keines für *fehlende* Typsicherheit. Im Gegenteil: Das Socket-Objekt hat Dir ganz klar gesagt, dass man Unicode-Strings nicht (direkt) über TCP transportieren kann, und also Byte-Strings benötigt. Wäre Python nicht typsicher, hätte das Socket-Objekt den Parameter irgendwie unsinnig interpretiert und Garbage übertragen.
Zweitens, weil Python schneller sein könnte, wenn zwischen Typen unterschieden würde.
Python unterscheidet zwischen den Typen - das *kostet* Zeit, anstatt Zeit einzusparen (auf die Zeit kann man aber nicht gut verzichten). Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (9)
-
Andreas Jung -
Falk Friedrich -
Fritz Cizmarov -
Georg Mischler -
Klaus-G. Meyer -
martin＠v.loewis.de -
Olaf 'Ruebezahl' Radicke -
Stefan Schwarzer -
Uwe Tapper