Also, wenn ich was an dem Unicode-Handling ändern möchte, muß ich mir erstmal klar werden, was mich stört. Meine verspätete Weihnachtsmannwunschliste:
1) "DeprecationWarning: Non-ASCII character" werde ersatzlos gestrichen und der Tag selbiger Tat werde in den Rang eines Nationalfeiertages erhoben.
2) print u"hübsch"
sollte keinen UnicodeEncodeError liefern, sondern den String per Latin-1 kodieren.
3) print u"hübsch" + "hübsch"
sollte keine UnicodeDecodeError liefern (wer weiss auf Anhieb, warum es hier einen DecodeError gibt und nicht einen EncodeError?) sondern
a) "hübsch" per Latin-1 dekodieren b) das Ergebnis per Latin-1 kodieren.
4) s = unicode("hübsch")
sollte keinen DecodeError liefern, sondern auf unicode("hübsch","latin-1") hinauslaufen, zumal für mein laienhaftes Unverständnis u"hübsch" die nicht-ausführliche-Version von unicode("hübsch") ist und u"hübsch" *keine* Exception wirft.
5) print "hübsch".decode("latin-1")
sollte keinen UnicodeEncodeError liefern (wer weiss auf Anhieb, warum "decode" einen "encode"-Fehler liefert? Hint: decode liefert den Fehler nicht, print tut es) sondern den String per Latin-1 kodieren.
Die Punkte 2-5 lassen sich umsetzen, indem man in site.py das defaultencoding auf "latin-1" setzt. Duh! Punkt 1 ist aus meiner Sicht eine minimale Codeänderung, nämlich die im C-Code fest eingebraute DeprecationWarning rauskommentieren.
Hab ich was vergessen?
Frage: Was sind eigentlich die gravierenden Nachteile eines geänderten defaultencodings?
Nachschlag: Kann ich in einem Script, das ich ausliefern möchte, das defaultencoding auf einfach weise auf latin-1 ändern? weil, die funktion wird ja in site.py aus dem namespace gelöscht.
Ciao, Gerson
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson Kurz wrote:
- "DeprecationWarning: Non-ASCII character" werde ersatzlos gestrichen und
der Tag selbiger Tat werde in den Rang eines Nationalfeiertages erhoben.
Willst Du das wirklich? Aus dieser Warnung wird irgendwann mal ein Syntaxfehler. Dann werden sich die Leute beschweren, nicht gewarnt worden zu sein.
- print u"hübsch"
sollte keinen UnicodeEncodeError liefern, sondern den String per Latin-1 kodieren.
Der Wunsch geht mit Python 2.3 in Erfüllung.
- print u"hübsch" + "hübsch"
sollte keine UnicodeDecodeError liefern (wer weiss auf Anhieb, warum es hier einen DecodeError gibt und nicht einen EncodeError?) sondern
(weil der Byte-String dekodiert wird, um zu dem Unicodestring addiert zu werden)
a) "hübsch" per Latin-1 dekodieren
Warum gerade Latin-1?
- s = unicode("hübsch")
sollte keinen DecodeError liefern, sondern auf unicode("hübsch","latin-1") hinauslaufen, zumal für mein laienhaftes Unverständnis u"hübsch" die nicht-ausführliche-Version von unicode("hübsch") ist und u"hübsch" *keine* Exception wirft.
Aus Rückwärtskompatibilität liefert u"hübsch" keine Exception. In Zukunft ist es ein Syntaxfehler, u"hübsch" im Quelltext zu haben, ohne die Kodierung des Quelltexts deklariert zu haben.
- print "hübsch".decode("latin-1")
sollte keinen UnicodeEncodeError liefern (wer weiss auf Anhieb, warum "decode" einen "encode"-Fehler liefert? Hint: decode liefert den Fehler nicht, print tut es) sondern den String per Latin-1 kodieren.
Nicht in 2.3.
Frage: Was sind eigentlich die gravierenden Nachteile eines geänderten defaultencodings?
a) Es ist eurozentrisch b) Es ist Windows-inkompatibel c) Es ist Mac-inkompatibel
Kurz: Du möchtest, dass ISO-8859-1 das default encoding ist. Einige Dich mit den Russen, die wollen koi8-r, mit den Chinesen, die wollen gb2312, und mit den Japanern, die wollen shift-jis (vielleicht auch euc-jp).
Ich persönlich will, dass UTF-8 das default encoding ist. Andere Deutsche verlangen bei der Gelegenheit immer, dass iso-8859-15 das default encoding ist. Warum ist Dein Wunsch besser als der Wunsch der Rest der Welt?
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Martin v. Loewis schrub:
- "DeprecationWarning: Non-ASCII character" werde ersatzlos gestrichen
und
Willst Du das wirklich? Aus dieser Warnung wird irgendwann mal ein Syntaxfehler. Dann werden sich die Leute beschweren, nicht gewarnt worden zu sein.
Bitte bitte sag daß das nicht wahr ist. Zeit für einen fork oder was?
Frage: Was sind eigentlich die gravierenden Nachteile eines geänderten defaultencodings?
a) Es ist eurozentrisch
Überraschung: ICH bin eurozentrisch. Insofern habe ich damit kein Problem.
b) Es ist Windows-inkompatibel c) Es ist Mac-inkompatibel
Daß muß man so formulieren:
b) Es ist Linux-kompatibel
und schon klingt es viel freundlicher ;)
Warum ist Dein Wunsch besser als der Wunsch der Rest der Welt?
Das ist die falsche Frage. Meine Gegenfrage lautet:
Warum muß ein Encodingproblem ein Programm hart beenden?
Nochmal: für relativ viele Probleme ist es mir wurschtegal, ob ü ? ist. Nicht-wurschtegal ist mir hingegen, ob das Encoding dazu führt, daß Probleme in für den Hauptzweck des Programmes völlig unrelevanten Bereichen wie sagen wir einem Logfile auftreten.
Du willst ein Beispiel aus der Praxis?
Ich spreche mit Geräten auf der Seriellen Leitung. Teure Geräte. Geräte bei denen du, da bin ich mir sicher, ziemlich sicher willst das sie FUNKTIONIEREN und nich nicht. Da werden Bytes übertragen. Die Bytes bestehen aus 8 Bit, d.h. es ist ganz natürlich daß da Zeug rüberkommt > 127. Kein Mensch der Welt spricht diese Sprache, es gibt also auch keinen Druck auf das Unicode-Konsortium, diese Sonderzeichen in gewaltige Schriftbilder umzusetzen.
Also, habe ich einen String x mit einem Sonderzeichen, sagen wir das beliebte ü drin. Das ist NICHT "das ü der Deutschen", sondern ein Zeichen, welches z.B. bedeutet "Sensor x ist aktiv", klar?
Jetzt will ich das ausgeben, z.B. so print "INPUT %s" % string_from_serial_port. Da gab es (dann wohl <2.3 habe ich aber nicht überprüft) exceptions. Toll! Oder, ich will den String in eine XML-Datei schreiben, geht natürlich. Dann will ich die Datei wieder lesen -> Programm beendet sich. (Datenbanken sind des Teufels, deshalb an dieser Stelle kein SQL-Beispiel, aber das geht vermutlich genauso).
Ciao, Gerson
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson Kurz wrote:
Willst Du das wirklich? Aus dieser Warnung wird irgendwann mal ein Syntaxfehler. Dann werden sich die Leute beschweren, nicht gewarnt worden zu sein.
Bitte bitte sag daß das nicht wahr ist. Zeit für einen fork oder was?
Es ist wahr. Vielleicht passiert es erst 2012.
Das ist die falsche Frage. Meine Gegenfrage lautet:
Warum muß ein Encodingproblem ein Programm hart beenden?
Das ist eine andere Frage, und Dein Vorschlag ist keine Antwort darauf. Auch wenn Latin-1 das default encoding ist, werden Programmer *immer noch* hart beendet, wenn ein Encodingproblem auftaucht (beispielsweise, wenn irgendwo das Euro-Zeichen vorkommt - was sogar in Europa vorkommen soll)
Du willst ein Beispiel aus der Praxis?
Nein danke, ich kenne die Probleme aus der Praxis. Glaub mir: Ich habe Deinen Wunsch verstanden. Nur kann ich Deinen Lösungsvorschlag nicht akzeptieren.
Also, habe ich einen String x mit einem Sonderzeichen, sagen wir das beliebte ü drin. Das ist NICHT "das ü der Deutschen", sondern ein Zeichen, welches z.B. bedeutet "Sensor x ist aktiv", klar?
Also Bytes - *keine* Zeichen (auch keine Sonderzeichen). Stino Bytes.
Jetzt will ich das ausgeben, z.B. so print "INPUT %s" % string_from_serial_port. Da gab es (dann wohl <2.3 habe ich aber nicht überprüft) exceptions.
Das glaube ich nicht. Wenn Du einen Byte-String hast, hat diese print-Anweisung in keiner Python-Version je ein Problem verursacht (höchstens vielleicht in IDLE - aber Du verwendest wohl nicht IDLE im Wirkbetrieb teurer Geräte, oder?)
Allerdings würde ich Bytes immer mit
print "INPUT %s" % repr(string_from_serial_port)
ausgeben - es könnte ja auch sein, dass da Steuerzeichen drin vorkommen, wenn man die Bytes als Zeichen interpretierte.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Gerson,
On Wed, 2003-12-31 07:46:46 +0100, Gerson Kurz wrote:
Martin v. Loewis schrub:
- "DeprecationWarning: Non-ASCII character" werde ersatzlos gestrichen und
Willst Du das wirklich? Aus dieser Warnung wird irgendwann mal ein Syntaxfehler. Dann werden sich die Leute beschweren, nicht gewarnt worden zu sein.
Bitte bitte sag daß das nicht wahr ist. Zeit für einen fork oder was? [...] Warum muß ein Encodingproblem ein Programm hart beenden?
Nochmal: für relativ viele Probleme ist es mir wurschtegal, ob ü ? ist. Nicht-wurschtegal ist mir hingegen, ob das Encoding dazu führt, daß Probleme in für den Hauptzweck des Programmes völlig unrelevanten Bereichen wie sagen wir einem Logfile auftreten.
Du willst ein Beispiel aus der Praxis? [...]
ich finde deine Begründung nicht ausreichend, um das standardmäßige Verhalten von Python zu ändern. Ich denke eher, dass deine Anforderungen eher die Ausnahme als die Regel sind, so dass man nicht die reguläre Python-Distribution mit dem entsprechend geänderten Verhalten "belasten" sollte.
Wenn ich in Python programmiere, will ich in einer mehrdeutigen Situation lieber eine Laufzeit-Exception als ein stilles Ignorieren eines möglichen Fehlers. Ich schätze das Motto "explicit is better than implicit" und die Konsistenz in Python, auch und gerade, was die Exceptions betrifft.
Ein anderes Beispiel: Wenn man int() einen String übergibt, der sich nicht in eine Zahl wandeln lässt, z. B. "123x", wird ein ValueError ausgelöst. Für einige Anwendungen wäre es völlig ausreichend, wenn int() in diesem Fall einfach den Wert 0 zurückliefern würde, aber ich finde gut, dass es nicht so ist. Wenn es einen undefinierten Zustand gibt, will ich das - ggf. durch einen Traceback, das übliche Python-Verhalten in solchen Fällen - wissen. Dass ich mein Programm entsprechend gut testen muss, halte ich für selbstverständlich.
Du hast ein Beispiel genannt, in dem du es lieber hättest, das Programm würde trotz unklarem Code ohne Exception weiterlaufen. Für deine spezielle Anwendung sehe ich allerdings auch andere Wege:
- Durch entsprechendes Design die Anzahl der möglichen fehlerträchtigen String-Umwandlungsstellen auf ein Minimum reduzieren und dort mit den normalen Python-Mitteln arbeiten. Das kann bspw. bedeuten, dass du für Schnittstellen, die immer mit Unicode arbeiten, Wrapper schreibst und in deiner eigenen Anwendung nur Byte-Strings verwendest. Eine Variante dieses Vorschlags ist ...
- Ausgaben eben nicht mit bspw. print erledigen, sondern eine eigene API verwenden, die Konvertierungsfehler ignoriert bzw. eigene Konvertierungsregeln umsetzt. (Ich weiß, dass das vielleicht nicht so einfach ist.)
- Einen Patch für eine konkrete Python-Implementierung, bspw. CPython, schreiben und für Leute, die ähnliche Probleme haben wie du, zum Download anbieten. Ein Fork, wie du ihn in deiner Mail in den Raum stellst, ist m. E. sicher übertrieben, es sei denn, du willst Python in eine grundsätzlich andere Richtung weiterentwickeln.
Viele Grüße Stefan
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Martin,
Kurz: Du möchtest, dass ISO-8859-1 das default encoding ist.
...
Ich persönlich will, dass UTF-8 das default encoding ist. Andere Deutsche verlangen bei der Gelegenheit immer, dass iso-8859-15 das default encoding ist. Warum ist Dein Wunsch besser als der Wunsch der Rest der Welt?
wie Du siehst, es gibt viele Encoding-Wünsche ;-) Warum also nicht was anbieten, um die Wünsche zu erfüllen?
Was spricht dagegen, in Py einen Befehl einzuführen, der es dem Entwickler überlässt, sein gewünschtes Default-Encoding für sein Script für Bytestrings zu setzen?
Sowas muß man ja für das Py-Quellfile auch schon angeben, zB: # -*- coding: Latin-1 -*-
Damit sage ich ja, dieses Sourcefile verwendet Latin-1 Coding.
Warum kann ich also in meinem Script durch einen Befehl nicht sagen: Alle meine Bytestrings verwenden Latin-1?
Vielleicht könnte man mit obigen Angabe in der Source auch gleich das Default-Encoding für Bytestrings vorbelegen?
kgm wrote:
Warum also nicht was anbieten, um die Wünsche zu erfüllen?
Was spricht dagegen, in Py einen Befehl einzuführen, der es dem Entwickler überlässt, sein gewünschtes Default-Encoding für sein Script für Bytestrings zu setzen?
Da gibt es mehrere Probleme:
1. Das encoding gilt nicht für ein Skript, sondern für die ganze Anwendung - man weiss hinterher ja nicht mehr, welcher String jetzt in welchem Modul generiert wurde.
2. Bytestrings und Unicode-Strings, die "gleich" sein sollen (also sich durch das default encoding ineinander umwandeln lassen sollen), müssen den gleichen Hash-Wert besitzen, sonst kann man sie nicht zusammen in einen Dictionary verwenden. Das ist nicht implementierbar, wenn man beliebige Encodings zulässt.
3. Woher weißt Du, als Programmautor, eigentlich, welche Encodings Deine Bytestrings haben? Das hängt doch auch davon ab, welche Encodings der Nutzer verwendet. Tatsächlich kann der Nutzer gegenwärtig schon ein anderes als 'us-ascii' als default encoding festlegen, indem er site.py ändert. Wenn Du sicher bist, dass Dein Skript ein bestimmtes Default encoding verwendet, mußt Du einfach sitecustomize.py anpassen.
Vielleicht könnte man mit obigen Angabe in der Source auch gleich das Default-Encoding für Bytestrings vorbelegen?
Was ist, wenn mehrere Module einer Anwendung verschiedene source encodings benutzen?
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Martin,
Da gibt es mehrere Probleme:
nach meiner Meinung gibt es die Probleme 1+3 mit der jetzigen Lösung schon genauso, ich sehe da keine echten neuen Probleme.
So ein Kodestück:
for tl in open("test.txt").readlines(): print tl
wird auch mit der jetzigen Py-Version nur dann wie gewünscht funktionieren, wenn der Anwender "sinnvoll" mitspielt, er also in test.txt das für sein System "passende" Encoding verwendet. Überraschenderweise ist das in der Praxis fast immer der Fall, dh, obiges Sript wird in der Praxis gut funktionieren, weil der User "mitspielt" und zur Erzeugung seiner Datei "text.txt" das "passende" Koding seines Systems verwendet. Py ist es völlig egal, welches das ist (Latin-1, koi8-r, was auch immer...). Wenn der User aber versucht, eine Datei von irgendeiner anderen Umgebung mit einem exotischen Koding (auch bei Zeichen < 128) ausgeben will, dann kommt Zeichenmüll raus, da kann Py noch soviel "aber USASCII ist doch mein Standard" rufen ;-)
Punkt 2 müsstest Du es noch etwas genauer erklären (Beispiel?), ich kenne Py-Interna nicht.
Das ist nicht implementierbar, wenn man beliebige Encodings zulässt.
Wo wären da zur jetzigen Lösung neue Probleme?
Default-Encoding für Bytestrings vorbelegen?
Streichen wir die Idee. Default-Vorbelegung könnte ja weiter USASCII bleiben.
Eins würde mich noch interessieren: Wie legt Py die u-Strings intern eigentlich ab? 2 Byte, glaube ich. Werden auch noch andere Infos ("Metadaten") abgelegt, zB, mit welchem Koding der String erstellt wurde?
Achja: Frohes neues Jahr! :-)
Mit freundlichen Grüßen Klaus Meyer :-)
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
kgm wrote:
So ein Kodestück:
for tl in open("test.txt").readlines(): print tl
wird auch mit der jetzigen Py-Version nur dann wie gewünscht funktionieren, wenn der Anwender "sinnvoll" mitspielt, er also in test.txt das für sein System "passende" Encoding verwendet.
Allerdings weißt Du nicht, welches Encoding in diesem Stück verwendet wird - und es ist dem Programm auch egal. Wenn Du also festlegst, welches Encoding das sein muss, schränkst Du Dein Programm ein.
Wenn der User aber versucht, eine Datei von irgendeiner anderen Umgebung mit einem exotischen Koding (auch bei Zeichen < 128) ausgeben will, dann kommt Zeichenmüll raus, da kann Py noch soviel "aber USASCII ist doch mein Standard" rufen ;-)
Genau. Deshalb sollte man sich *nie* auf das default encoding verlassen, sondern *immer* selbst im Programm die Kodierungen angeben, soweit man sie weiß; in den anderen Fällen sollte man versuchen, Bytes nicht als Zeichen zu interpretieren.
Punkt 2 müsstest Du es noch etwas genauer erklären (Beispiel?), ich kenne Py-Interna nicht.
d = {'nice':1} print d[u"nice"]
muss funktionieren; in Erweiterung auch
d = {'schön':1} print d[u"schön"]
Wo wären da zur jetzigen Lösung neue Probleme?
Gegenwärtig ist garantiert, dass der Hashwert von Unicode-Strings der gleiche ist wie der Hashwert von Bytestrings, sofern in beiden Fällen Werte < 128 verwendet werden. Wenn man aber beispielsweise iso-8859-15 zum Default encoding macht, müsste u"\u20ac" und "\xa4" den gleichen Hashwert liefert - ist das Encoding hingegen iso-8859-1, müssten u"\u00x4" und "\x4" den gleichen Hashwert liefern. Gleichzeitig sollten u"\u20ac" und u"\u00a4" verschiedene Hashwerte haben.
Nenne einen Hashalgorithmus, der als Parameter das encoding hat und diese Forderungen erfüllt! (natürlich auch die normalen Forderungen an eine Hashfunktion: das identisch selbe Objekt liefert immer den gleichen Hashwert usw.)
Wie legt Py die u-Strings intern eigentlich ab? 2 Byte, glaube ich.
Das ist eine Konfigurationsoption: 2 oder 4 Byte (--enable-ucs)
Werden auch noch andere Infos ("Metadaten") abgelegt, zB, mit welchem Koding der String erstellt wurde?
Der Hashwert wird gecached, sowie der Bytestring, der sich nach Anwendung des default encoding ergibt (falls der Unicodestring in einen Bytestring umgewandelt wurde). Deshalb darf man das default encoding auch nicht nachträglich ändern: die gecacheten Strings wären alle ungültig.
Frohes Neues Jahr, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Martin,
Nenne einen Hashalgorithmus, der als Parameter das encoding
bevor ich nach einen umöglichen Algorithmus suche, hätte ich mich eher an die Empfehlungen von unicode.org gehalten ;-)
Programs should always compare canonical-equivalent Unicode strings as equal. One of the easiest ways to do this is to use a normalized form for the strings: if strings are transformed into their normalized forms, then canonical-equivalent ones will also have precisely the same binary representation.
Aber da die Feiertage vorbei sind und der Ernst des Lebens wieder beginnt (Arbeit), für die Mitleser sich das Wort Unicode langsam zum Reizwort entwickelt und ich eigentlich ja früher schon sagte, das ich nichts mehr dazu sagen will, soll es von meiner Seite her genug sein.
Andererseits möchte ich mich nicht als Herr über diesen Thread aufschwingen, wer also gerne noch was schreiben möchte, bitte. ;-)
kgm wrote:
Hi Martin,
Nenne einen Hashalgorithmus, der als Parameter das encoding
bevor ich nach einen umöglichen Algorithmus suche, hätte ich mich eher an die Empfehlungen von unicode.org gehalten ;-)
Programs should always compare canonical-equivalent Unicode strings as equal. One of the easiest ways to do this is to use a normalized form for the strings: if strings are transformed into their normalized forms, then canonical-equivalent ones will also have precisely the same binary representation.
Das bezieht sich aber auf was ganz anderes, nämlich die Tatsache, daß es bei zusammengesetzten Zeichen (wie z.B. Umlauten) (manchmal) zwei Möglichkeiten gibt, diese in Unicode darzustellen.
1) Als vorgefertiges Zeichen (z.B. ü als U+00fc) 2) Als Basiszeichen gefolgt vom Accent-Zeichen (dem sogenannten "Non-spacing mark", also ein Zeichen, das selber keinen Platz braucht, aber das vorherigen Zeichen überlappt, bzw. modifiziert) (das ü als U+0075 U+0308)
BTW, zum Zerlegen und Zusammensetzen von zusammengesetzten Zeichen gibts in Python 2.3 unicodedata.normalize:
import unicodedata unicodedata.normalize("NFD", u"ü")
u'u\u0308'
unicodedata.normalize("NFC", u"u\u0308")
u'\xfc'
Mit Encoding hat das ganze *überhaupt nix* zu tun.
Bis demnächst, Walter Dörwald
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo,
Martin v. Loewis wrote: MvL> Gerson Kurz wrote:
- print u"hübsch"
sollte keinen UnicodeEncodeError liefern, sondern den String per Latin-1 kodieren.
MvL> Der Wunsch geht mit Python 2.3 in Erfüllung. Kann ich mit Python 2.3.2 nicht nachvollziehen. Bei mir liefert es einen UnicodeEncodeError.
Übrigens: hat jemand 'ne Ahnung ob und wie das Unicode Zeug in Ruby gelöst ist?
grüße, Marek
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Marek Kubica wrote:
MvL> Der Wunsch geht mit Python 2.3 in Erfüllung. Kann ich mit Python 2.3.2 nicht nachvollziehen. Bei mir liefert es einen UnicodeEncodeError.
Welches Betriebssystem, welche Terminalemulation, was ist sys.stdout.encoding? Hast Du die print-Anweisung interaktiv eingegeben oder in eine Datei geschrieben?
Übrigens: hat jemand 'ne Ahnung ob und wie das Unicode Zeug in Ruby gelöst ist?
Soweit ich weiß: gar nicht.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi!
MvL> Welches Betriebssystem, welche Terminalemulation, was ist MvL> sys.stdout.encoding? Hast Du die print-Anweisung interaktiv MvL> eingegeben oder in eine Datei geschrieben? OS: Win32, genauer: WinXP SP1 (deutsch) sys.stdout.encoding 'cp850' interaktive python shell
Übrigens: hat jemand 'ne Ahnung ob und wie das Unicode Zeug in Ruby gelöst ist?
MvL> Soweit ich weiß: gar nicht. Zumindest ist Python nicht hinterher, das ist schon mal was ;)
grüße, Marek
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Marek Kubica wrote:
MvL> Welches Betriebssystem, welche Terminalemulation, was ist MvL> sys.stdout.encoding? Hast Du die print-Anweisung interaktiv MvL> eingegeben oder in eine Datei geschrieben? OS: Win32, genauer: WinXP SP1 (deutsch) sys.stdout.encoding 'cp850' interaktive python shell
Ah, ok. Probier' mal ein Script. Im interaktiven Modus wird für Unicode-Literale Latin-1 angenommen; das stimmt nicht, wenn das Terminal tatsächlich cp850 ist.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Von was träumst Du? Warum in der Welt sollte Python per Default alles was Umlaute hat als Latin-1 behandeln? Wir leben in einer internationalen Welt in der es noch andere Encodings neben Latin1 gibt. Du vertrittst die gleiche egoistische Sichtweise wie unsere amerikanischen Freunde, die nur ASCII und sonst nicht kennen. Genau diese Sichtweise hat z.B. dazu geführt, dass Zope lange Zeit sehr ASCII zentriert war und Unicodesupport ein Fremdwort war.
Die Voreinstellung von ASCII als Defaultencoding wurde von GvR ganz bewusst so gewählt (nämlich aus den genannten Gründen, dass man es sonst niemanden recht machen kann). ASCII ist nun mal der kleinester gemeinsame Nenner). Wenn Du etwas anderes haben willst, dann musst Du es explizit konfigurieren. Insofern bleibt Dein Traum ein Traum.
-aj
--On Dienstag, 30. Dezember 2003 21:53 Uhr +0100 Gerson Kurz Gerson.Kurz@t-online.de wrote:
Also, wenn ich was an dem Unicode-Handling ändern möchte, muß ich mir erstmal klar werden, was mich stört. Meine verspätete Weihnachtsmannwunschliste:
- "DeprecationWarning: Non-ASCII character" werde ersatzlos gestrichen
und der Tag selbiger Tat werde in den Rang eines Nationalfeiertages erhoben.
- print u"hübsch"
sollte keinen UnicodeEncodeError liefern, sondern den String per Latin-1 kodieren.
- print u"hübsch" + "hübsch"
sollte keine UnicodeDecodeError liefern (wer weiss auf Anhieb, warum es hier einen DecodeError gibt und nicht einen EncodeError?) sondern
a) "hübsch" per Latin-1 dekodieren b) das Ergebnis per Latin-1 kodieren.
- s = unicode("hübsch")
sollte keinen DecodeError liefern, sondern auf unicode("hübsch","latin-1") hinauslaufen, zumal für mein laienhaftes Unverständnis u"hübsch" die nicht-ausführliche-Version von unicode("hübsch") ist und u"hübsch" *keine* Exception wirft.
- print "hübsch".decode("latin-1")
sollte keinen UnicodeEncodeError liefern (wer weiss auf Anhieb, warum "decode" einen "encode"-Fehler liefert? Hint: decode liefert den Fehler nicht, print tut es) sondern den String per Latin-1 kodieren.
Die Punkte 2-5 lassen sich umsetzen, indem man in site.py das defaultencoding auf "latin-1" setzt. Duh! Punkt 1 ist aus meiner Sicht eine minimale Codeänderung, nämlich die im C-Code fest eingebraute DeprecationWarning rauskommentieren.
Hab ich was vergessen?
Frage: Was sind eigentlich die gravierenden Nachteile eines geänderten defaultencodings?
Nachschlag: Kann ich in einem Script, das ich ausliefern möchte, das defaultencoding auf einfach weise auf latin-1 ändern? weil, die funktion wird ja in site.py aus dem namespace gelöscht.
Ciao, Gerson
Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (7)
-
Andreas Jung -
Gerson.Kurz＠t-online.de -
kgm -
Marek Kubica -
Martin v. Loewis -
Stefan Schwarzer -
Walter Dörwald