Hallo Andreas, On 2006-08-28 16:07, Andreas Pakulat wrote:

On 28.08.06 15:11:17, Stefan Schwarzer wrote:

...

Hallo Alexander,

On 2006-08-28 12:43, Alexander 'boesi' Bösecke wrote:

...

Mein Problem ist nun, dass wenn stdout nicht sichtbar ist (also auch nicht umgeleitet wird) und mit print Nicht-ASCII-Zeichen ausgegeben werden, werden alle nachfolgenden Befehle schlicht ignoriert. Das angehängte use_wx.py demonstriert dies. Wird das Programm mit 'python use_wx.py' ausgeführt, erscheinen 2 Message-Boxes und 'ä' wird auf stdout ausgegeben. Wird das Programm dagegen mit 'pythonw.exe ausgeführt, erscheint nur die 1. Message-Box. Wird 'ä' durch 'a' ersetzt, erscheinen in jedem Fall 2 Message-Boxes. wenn ich dein Beispiel-Progrämmchen use_wx.py auf meinem Rechner (Gentoo Linux) in einem xterm ausführe, bekomme ich nach dem Klick auf die Schaltfläche "Test" einen Traceback:

Traceback (most recent call last): File "/tmp/use_wx.py", line 15, in test print u'ä' UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range(128)

Dann hast du die erste Zeile des Programms entfernt oder benutzt ein uraltes Python. Offensichtlich denkt dein Python naemlich der Quellcode waere in ascii, ist er aber nicht, was auch mit der Zeile

# -*- coding: utf_8 -*-

angegeben wird. Hier mit python2.4 funktioniert das wunderbar, sowohl mit UTF-8 als auch Latin1 Umgebung.

weder das eine noch das andere. Die erste Zeile ist drin und ich verwende Python 2.4.3. Ich habe festgestellt, dass ich das Skript mit DOS-Zeilenenden gespeichert hatte, aber selbst, wenn ich es konvertiere, bekomme ich den Traceback. Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Dann hast du die erste Zeile des Programms entfernt oder benutzt ein uraltes Python. Offensichtlich denkt dein Python naemlich der Quellcode waere in ascii, ist er aber nicht, was auch mit der Zeile

# -*- coding: utf_8 -*-

angegeben wird. Hier mit python2.4 funktioniert das wunderbar, sowohl mit UTF-8 als auch Latin1 Umgebung.

Das stimmt nicht. Diese Deklaration fuehrt einzig und alleine dazu, das unicode-literale mit dem entsprechenden encoding ausgewerted werden & dann zu unicode gewandelt. Alexanders Problem hingegen haengt mit der Wandlung eines unicode-strings zu eineim byte-string fuer die Ausgabe zusammen. Ich weiss nicht genau, wie python dazu kommt ein encoding an sys.stdout zu pappen - und es kann sein, das dies unter bestimmten Umstaenden eben nicht geht. Was aber auf jeden Fall klappen sollte: sys.stdout durch einen encoding-stream aus dem codecs modul zu ersetzen. Dann sollte das unter allen Umstaenden gehen. Also etwa so in der Art: sys.stdout = codecs.EncodedFile(sys.stdout, data_encoding="utf-8", errors="foo") Das foo ist natuerlich unsinn - aber ich finde im Moment nicht die moeglichen Werte ausser dem default strict - welcher an dieser Stelle fuer debugging-Zwecke vielleicht duerch eine relaxtere Variante ersezts werden sollte. Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Hi Am 28.08.2006 17:41:28 schrieb Diez B. Roggisch:

Was aber auf jeden Fall klappen sollte: sys.stdout durch einen encoding-stream aus dem codecs modul zu ersetzen. Dann sollte das unter allen Umstaenden gehen.

Also etwa so in der Art:

sys.stdout = codecs.EncodedFile(sys.stdout, data_encoding="utf-8", errors="foo")

Wenn ich in die beiden oben geposteten Skripte das einfüge: ---snip--- import sys, codecs sys.stdout = codecs.EncodedFile(sys.stdout, data_encoding='utf8', file_encoding='utf8', errors='replace') ---snap--- ... bekomme ich folgenden Fehler: ---snip--- Traceback (most recent call last): File "only_w32.py", line 8, in ? print u'+ñ' File "c:\tools\python\Lib\codecs.py", line 508, in write data, bytesdecoded = self.decode(data, self.errors) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range (128) ---snap--- Wie kommt da der ascii codec hin? Ich hab doch utf8 angegeben, oder nicht?

Das foo ist natuerlich unsinn - aber ich finde im Moment nicht die moeglichen Werte ausser dem default strict - welcher an dieser Stelle fuer debugging-Zwecke vielleicht duerch eine relaxtere Variante ersezts werden sollte.

aus der Python-Doku zu codecs.register(): ---snip--- Possible values for errors are 'strict' (raise an exception in case of an encoding error), 'replace' (replace malformed data with a suitable replacement marker, such as "?"), 'ignore' (ignore malformed data and continue without further notice), 'xmlcharrefreplace' (replace with the appropriate XML character reference (for encoding only)) and 'backslashreplace' (replace with backslashed escape sequences (for encoding only)) as well as any other error handling name defined via register_error(). ---snap--- cu boesi PS: Den Traceback bekomm ich natürlich nur zu sehen, wenn ich python.exe verwende. Bei pythonw.exe seh ich wie gehabt nix, aber das Verhalten ist das gleiche. -- <THammY-> und meine hände ham bisher immer nur das gemacht was ich will </THammY> _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Hi Am 28.08.2006 22:48:01 schrieb Martin Richtarsky:

Das Problem ist, dass im Fall von pythonw.exe das Encoding nicht gesetzt wird (siehe Nachricht von Martin v. Löwis), also wird zur Ausgabe der ASCII-Codec verwendet.

Aber ist das nicht irgendwie schizophren - erst wird das Encoding weggeworfen (oder halt nicht gesetzt) und dann wird ein Traceback (wegen falschem Encoding) ins nirgendwo geschickt? Wenn der print-Befehl schon ausgeführt wird, sollten dann diese EncodeErrors nicht ignoriert werden? Oder überseh ich jetzt irgendwas? So what is it? Bug or feature?

Füg' mal das am Anfang in dein Skript ein: import locale locale.setlocale(locale.LC_ALL, '')

Das setzt die Locale im Nachhinein und sollte auch unter pythonw.exe beim Encoding dasselbe einstellen wie bei python.exe (unter englischem Windows 2000 ist das bei mir CP437).

In beiden Fällen ändert sich bei mir die Ausgabe von locale.getlocale(locale.LC_ALL) von (None, None) auf ['de_DE', '1252']. Sonst ändert sich aber nix... cu boesi -- <seasons82> was ist rl? <seasons82> und muss man das wissen? ...der moment wo einem klar wird, dass man zuviel chattet... _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Hi Am 29.08.2006 11:52:56 schrieb Martin Richtarsky:

"Encoding nicht gesetzt" soll in dem Fall heissen, dass der Default verwendet wird. Das ist dann ASCII. Python versucht bei der Ausgabe von Unicode-Strings (auch bei write(), wie mir gerade aufgefallen ist) immer, die entsprechend zu encoden.

Also letzten Endes ist der Fehler eine Verkettung unglücklicher Umstände? Weil wenn kein Terminal vorhanden ist, kann kein Encoding bestimmt werden. Soweit klar... [1] Das heisst aber auch, wenn pythonw.exe verwendet wird muss man entweder ... 1. auf Nicht-ASCII-Zeichen (bzw Unicode-Strings) verzichten 2. die Strings händisch umgewandeln 3. das Encoding nachträglich setzen 1&2 sind nicht wirklich praktikabel. Und für den Punkt 3 stellt sich mir die Frage, welches Encoding ich verwende, damit die Software überall funktioniert. Wenn ich den Link von Jens richtig verstanden hab und das mit der Methode von Diez kombiniere: if sys.stdout.encoding is None: import codecs fse = sys.getfilesystemencoding() sys.stdout = codecs.getwriter(fse)(sys.stdout) ... hab ich eine hinreichend portable Lösung oder? Unter portabel verstehe ich in diesem Fall, dass auf *keinem* System eine Fehlermeldung kommt und auf möglichst vielen Systemen die Zeichen korrekt dargestellt werden.

...

In beiden Fällen ändert sich bei mir die Ausgabe von locale.getlocale(locale.LC_ALL) von (None, None) auf ['de_DE', '1252']. Sonst ändert sich aber nix...

Und was sagt sys.stdout.encoding?

Das scheint von locale unabhängig zu sein... python.exe: CP850 pythonw.exe: None Seltsamerweise ändert sich daran auch nix, wenn ich das Encoding wie oben geschrieben, ändere. Bei MinGW kommt dagegen immer None, aber ich denke das liegt daran, dass GetConsoleOutputCP da nix vernüftiges liefert, oder?[2] Allerdings bekomme ich mit der Methode oben auch unter MinGW den richtigen Output (also mit korrekt dargestellten Umlauten).

Die Methode von Diez funktioniert bei mir unter Windows 2000.

Bei mir auch, da war ich etwas voreilig. Ich hatte testweise aus dem print u'ä' ein print 'ä' gemacht. Das kann natürlich nicht funktionieren, aber dummerweise hatte ich diese Version auf den W2k-Rechner kopiert. cu boesi [1] nicht klar ist mir dagegen, warum encoding=None bedeutet, dass das default-encoding verwendet wird. Intuitiv würde ich sagen encoding=None, bedeutet der String wird so ausgegeben wie er ist (also einfach als Folge von Bytes). Es ist auf jeden Fall ein ganz merkwürdiges Verhalten, wenn ein print-Befehl nur dann zu einem Absturz führt, wenn der Output des Befehls nicht sichtbar ist. [2] ich nutze da auch die normale Windows-Version von Python. -- <seasons82> was ist rl? <seasons82> und muss man das wissen? ...der moment wo einem klar wird, dass man zuviel chattet... _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Am Sonntag, 10. September 2006 11:14 schrieb Martin v. Löwis:

Alexander 'boesi' Bösecke schrieb:

...

...

Das Problem ist, dass im Fall von pythonw.exe das Encoding nicht gesetzt wird (siehe Nachricht von Martin v. Löwis), also wird zur Ausgabe der ASCII-Codec verwendet.

Aber ist das nicht irgendwie schizophren - erst wird das Encoding weggeworfen (oder halt nicht gesetzt) und dann wird ein Traceback (wegen falschem Encoding) ins nirgendwo geschickt?

Das encoding von sys.stdout wird deshalb nicht gesetzt, weil kein sinnvoller Wert dafür ermittelt werden kann. Der Traceback wird ganz normal auf den STDOUT-Handle des Betriebssystems ausgegeben. In einer Windows-Anwendung ist es dann Windows, was die Ausgabe verwirft.

Sorry, aber die Urprungsmail ist bei mir wegen Mailrouting Problemen nicht angekommen. Also packe ich meinen Senf hier rein.. Alexander, warum stellst Du nicht ein passendes Encoding selbst ein, sinnvollerweise relativ früh in __main__? Dann kannst Du auch die 'ignore' Option mitgeben, falls Du keine hinreichende Kontrolle übers encoding Deines Script-I/Os hast.. Pete _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Hi Am 10.09.2006 11:14:09 schrieb Martin v. Löwis:

Das encoding von sys.stdout wird deshalb nicht gesetzt, weil kein sinnvoller Wert dafür ermittelt werden kann. Der Traceback wird ganz normal auf den STDOUT-Handle des Betriebssystems ausgegeben. In einer Windows-Anwendung ist es dann Windows, was die Ausgabe verwirft.

Danke für die Klarstellung, wer wofür verantwortlich ist.

...

Wenn der print-Befehl schon ausgeführt wird, sollten dann diese EncodeErrors nicht ignoriert werden? Oder überseh ich jetzt irgendwas?

Dieses Argument verstehe ich nicht. Fehler sollten nie ignoriert werden, es sei denn, die Anwendung ignoriert sie explizit (siehe auch den Zen von Python).

Das ist mir schon klar. Nur in meinem Verständnis gehört zu einem Fehler auch eine verwertbare Fehlermeldung. Und die ist hier ja nicht gegeben. Ganz im Gegenteil, wenn es eine (sichtbare) Fehlermeldung geben könnte, tritt der Fehler nicht auf. Man könnte vielleicht auch so argumentieren, wenn kein stdout sichtbar ist, ist dies ein explizites Ignorieren von Encoding-Fehlern. Aber diese Argumentation ist schon wieder ziemlich implizit. Vielleicht sollte der print-Befehl auch keinen EncodeError auslösen, sondern eher ein "EncodeWarning"? Mir fällt keine sinnvolle Anwendung ein, wo ein Encoding-Fehler wirklich kritisch wäre (in Verbindung mit dem print-Befehl).

...

So what is it? Bug or feature?

Es ist m.E. ein Bug, dass in pythonw sys.stdout.encoding nicht gesetzt ist. Allerdings kann ich mir keine vernünftige Codeänderung vorstellen, die diesen Bug behebt. Patches sind herzlich willkommen.

Man müsste erkennen, dass Windows stdout "ins nichts" leitet, und könnte dann gefahrlos encoding auf "UTF-8" setzen.

Warum kann man nicht UTF-8 als Standard anstatt ASCII nehmen? Wenn ein Encoding-Fehler bei sichtbaren stdout auftritt, ist das ja leicht erkennbar (und behebbar).

Ich weiß aber keine Win32-API-Rufe, mit denen man erkennen kann, dass der stdout-Filehandle ins nichts geht.

Einer der vielen Gründe, warum ich Python so mag, ist das ich mich gerade nicht mit der Win32-Api rumschlagen muss... cu boesi -- --==SECURITY ALERT==-- Your Computer Is Currently Broadcasting An Internet IP Address. With This Address, Someone Can Begin Attacking Your Computer. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Hi

Am 28.08.2006 17:41:28 schrieb Diez B. Roggisch:

...

Was aber auf jeden Fall klappen sollte: sys.stdout durch einen encoding-stream aus dem codecs modul zu ersetzen. Dann sollte das unter allen Umstaenden gehen.

Also etwa so in der Art:

sys.stdout = codecs.EncodedFile(sys.stdout, data_encoding="utf-8", errors="foo")

Wenn ich in die beiden oben geposteten Skripte das einfüge:

---snip--- import sys, codecs sys.stdout = codecs.EncodedFile(sys.stdout, data_encoding='utf8', file_encoding='utf8', errors='replace') ---snap---

... bekomme ich folgenden Fehler:

---snip--- Traceback (most recent call last): File "only_w32.py", line 8, in ? print u'+ñ' File "c:\tools\python\Lib\codecs.py", line 508, in write data, bytesdecoded = self.decode(data, self.errors) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in

Alexander 'boesi' Bösecke schrieb: position 0: ordinal not in range

(128) ---snap---

Wie kommt da der ascii codec hin? Ich hab doch utf8 angegeben, oder nicht?

Hm, verstehe ich auch nicht. Ich haette gedacht das es geht - aber das hier tuts auf jeden Fall: # -*- coding: utf-8 -*- import sys, codecs t = u"ä" sys.stdout = codecs.getwriter("utf-8")(sys.stdout) print t MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Danke das funktioniert ohne Fehlermeldung, aber die Windows-Console (cmd.exe) interpretiert das 'ä' als 2 Zeichen. Das ist zwar nicht weiter tragisch, aber zumindest unschön, weil's ohne dem ja korrekt dargestellt wird.

Das kannst du durch verveden von cp1252 statt utf-8 reparieren. Wie MvL ja schon ausgefuehrt hat, versucht python das encoding des terminals zu raten. Wenn das nicht geht, muss man die eben "von Hand" synchronisieren. Unter meinen *nix OSsen kann ich halt immer utf-8 einstellen, darum habe ich das gemacht.

Ok ich kann noch eine Abfrage 'sys.stdout.isatty()' einbauen, aber irgendwie ist das dann von hinten durch die Brust ins Auge...

....

Moment Kommando zurück, das funktioniert nur mit XP und nicht mit W2k. Unter W2k beschwert sich Python mit: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128) Ausserdem interpretiert cmd.exe unter W2k das 'ä' als 2 Zeichen, wenn stdout nicht verbogen wird.

Kannst du das vielleicht in nem kleinen script illustrieren? Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de