Unicode, warum ASCII als default, warum nicht Latin-1 ???
Hallo,
im Module site.py steht:
# Set the string encoding used by the Unicode implementation. The # default is 'ascii', but if you're willing to experiment, you can # change this.
Warum auf Ascii, warum nicht auf Latin-1?
Latin-1 entspricht in den 256 unteren Zeichen exakt der Unicode-Definition. Die unteren 128 Zeichen sind exakt Ascii. Es wäre kompatibel zu alten Ascii-Programmen. Es wären sowohl die Amerikaner als auch die meisten Europäer mit dieser Auswahl bestimmt "glücklicher".
Mir fällt einfach kein überzeugender Grund ein, warum nur Ascii? Natürlich ist es gegenüber irgendwelchen Sprachen immer ungerecht, eine bestimmte Kodierung als Default zu wählen, aber das ist es mit Ascii im Prinzip genauso (man könnte ja auch EBCDI nehmen...). Ich denke, Latin-1 wäre ein besserer Kompromiss.
Ausserdem frage ich mich, warum es keine Möglichkeit gibt, zumindest im Script diesen Wert gloabl für den laufenden Script zu ändern? Es gibt nur den unbefriedigenden Weg, über sitecustomize.py den Wert zu überschreiben...
Vielleicht hat ja noch jemand ein Argument, warum das unbedingt Ascii sein muss.
Ganz einfach: GvR hat das entschieden und damit Basta :-). Es gibt keinen Grund der ganzen Welt latin-1 als Standard vorzugeben (Griechen benutzen Latin-7... von den asiastischen Staaten mal ganz abgesehen). Also ist ASCII der kleinste gemeinsame Nenner. Wenn Du was anderes brauchst, ändere es eben.
explicit-is-better-than-implicit
-aj --On Sonntag, 4. Mai 2003 23:18 Uhr +0200 Klaus Meyer km-news1@onlinehome.de wrote:
Hallo,
im Module site.py steht:
# Set the string encoding used by the Unicode implementation. The # default is 'ascii', but if you're willing to experiment, you can # change this.
Warum auf Ascii, warum nicht auf Latin-1?
Latin-1 entspricht in den 256 unteren Zeichen exakt der Unicode-Definition. Die unteren 128 Zeichen sind exakt Ascii. Es wäre kompatibel zu alten Ascii-Programmen. Es wären sowohl die Amerikaner als auch die meisten Europäer mit dieser Auswahl bestimmt "glücklicher".
Mir fällt einfach kein überzeugender Grund ein, warum nur Ascii? Natürlich ist es gegenüber irgendwelchen Sprachen immer ungerecht, eine bestimmte Kodierung als Default zu wählen, aber das ist es mit Ascii im Prinzip genauso (man könnte ja auch EBCDI nehmen...). Ich denke, Latin-1 wäre ein besserer Kompromiss.
Ausserdem frage ich mich, warum es keine Möglichkeit gibt, zumindest im Script diesen Wert gloabl für den laufenden Script zu ändern? Es gibt nur den unbefriedigenden Weg, über sitecustomize.py den Wert zu überschreiben...
Vielleicht hat ja noch jemand ein Argument, warum das unbedingt Ascii sein muss.
-- Mit freundlichen Grüßen Klaus Meyer :-)
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
Andreas Jung andreas@andreas-jung.com writes:
Ganz einfach: GvR hat das entschieden und damit Basta :-). Es gibt keinen Grund der ganzen Welt latin-1 als Standard vorzugeben (Griechen benutzen Latin-7... von den asiastischen Staaten mal ganz abgesehen). Also ist ASCII der kleinste gemeinsame Nenner.
Genau. Ich persönlich hätte noch UTF-8 als Default akzeptiert: Es hat ebenfalls die unteren 128 Zeichen wie ASCII, und unterstützt alle Zeichen, die die Europäer so brauchen, *und* alle Zeichen, die der Rest der Welt braucht.
In the face of ambiguity, refuse the temptation to guess.
Weil sich der Streit "mein Encoding ist besser als Deins" nicht entscheiden lässt, und Latin-1 auch nur eins unter vielen ist, und gegenüber UTF-8 den Nachteil hat, nicht alle Zeichen zu unterstützen, ist es nicht ausgewählt worden.
Wenn Du was anderes brauchst, ändere es eben.
Das empfehle ich nicht; vom system default encoding sollte man sowenig wie möglich Gebrauch machen. Statt dessen sollte man stets explizit das Encoding in .encode und .decode angeben.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Ganz einfach: GvR hat das entschieden und damit Basta :-)
Starkes Argument ;-) Nur wenig überzeugend... :-( Die ASCII-Lösung bricht zT leider auch alten Kode! (zB bei Filenamen mit Umlauten)
Genau. Ich persönlich hätte noch UTF-8 als Default akzeptiert: Es hat
Schade das in site.py nicht # Enable to support locale aware default string encodings. dieses Stückchen Kode aktiv ist. Das wäre bestimmt eine brauchbare Lösung gewesen. Keine Ahnung, warum das nicht aktiv ist, vielleicht ist es nicht 100% sicher?
Weil sich der Streit "mein Encoding ist besser als Deins" nicht
Dies "Locale default string encoding" wäre aber ein "gerechtere" Lösung gewesen. Ausserdem ist mit der Entscheidung für ASCII ja auch ein Coding ausgewählt worden, also war die Entscheidung auch wilkürlich. Gudio ist wohl schon zu lange in USA und hat leider auch kein Umlaut im Namen ;-)
Das empfehle ich nicht; vom system default encoding sollte man sowenig wie möglich Gebrauch machen. Statt dessen sollte man stets explizit das Encoding in .encode und .decode angeben.
Da hast Du sicher recht, wenn ich zB ein Script jemanden gebe, kann ich kaum von Ihm verlangen, dafür erstmal site.py zu ändern.... Aber es ist Mehraufwand, wo es oft auch ohne gegangen wäre. Das sollten wir übrigens den Scriptschreibern mit "nur ASCII" unbedingt auch beibringen - falls die Ihr Script ausserhalb ASCII-Ländern verteilen wollen...
Naja, ich will da auch nicht länger drauf rumreiten, auch wenn man das vielleicht jetzt noch für 2.3 verbessern könnte (obigen Kode aktivieren), aber meine Meinung ist, dass das keine gute Entscheidung war und das noch viele Jahre Ärger machen wird!
Klaus Meyer km-news1@onlinehome.de writes:
Die ASCII-Lösung bricht zT leider auch alten Kode! (zB bei Filenamen mit Umlauten)
Das stimmt nicht. Dateinamen mit Umlauten funktionieren problemlos, wenn sie in Bytestrings abgespeichert werden. Falls sie in altem Kode vorkommen, müssen sie ja wohl in Bytestrings repräsentiert gewesen sein.
Keine Ahnung, warum das nicht aktiv ist, vielleicht ist es nicht 100% sicher?
Einerseits ist es falsch, andererseits eine potentielle Quelle unverständlicher Fehler.
Es ist falsch, weil locale.getdefaultlocale nicht immer ein vernünftiges Ergebnis liefert. Das ist eine Design-Einschränkung: locale.getdefaultlocale *kann* nicht richtig funktionieren.
Es ist eine Quelle unverständlicher Fehler, weil ein Skript, was auf einem Rechner Klasse funktioniert auf einem anderen plötzlich scheitert. "und ich habe nichts geändert"
Dies "Locale default string encoding" wäre aber ein "gerechtere" Lösung gewesen. Ausserdem ist mit der Entscheidung für ASCII ja auch ein Coding ausgewählt worden, also war die Entscheidung auch wilkürlich. Gudio ist wohl schon zu lange in USA und hat leider auch kein Umlaut im Namen ;-)
Ich habe einen Umlaut im Namen, und war auch entschieden dagegen, dass Latin-1 das default encoding wird. Das hat nichts mit Amerikazentrismus zu tun, sondern folgt der einfachen Regel
In the face of ambiguity, refuse the temptation to guess.
Wenn etwas aussieht wie ASCII und man weiß, dass es Text ist, dann ist es auch ASCII - einfach weil ASCII ein Teil nahezu jeder anderen Kodierung ist.
Wenn etwas nicht wie ASCII aussieht, kann man nur raten. *Jede* andere Kodierung würde u.U. falsch raten. Wählt man beispielsweise die Kodierung der locale, so bekommt man unter Windows cp1252. Das führt dann evtl. dazu, dass ein Programm falsches HTML geneneriert und das nicht merkt. Beispiele für dieses konkrete Problem (EURO-Zeichen in sog. Latin-1-Text) finden sich im Web viele - Python sollte das nicht auch noch unterstützen.
Da hast Du sicher recht, wenn ich zB ein Script jemanden gebe, kann ich kaum von Ihm verlangen, dafür erstmal site.py zu ändern.... Aber es ist Mehraufwand, wo es oft auch ohne gegangen wäre.
Mit "oft" meinst Du "bei den meisten Eingabedaten"? Das ist m.E. eine gefährliche Strategie. Wenn ein Programm bei manchen Eingabedaten richtig funktioniert und bei anderen nicht, sollte das nach Möglichkeit schon den Autoren auffallen, und nicht erst im laufenden Betrieb.
Errors should never pass silently.
Naja, ich will da auch nicht länger drauf rumreiten, auch wenn man das vielleicht jetzt noch für 2.3 verbessern könnte (obigen Kode aktivieren), aber meine Meinung ist, dass das keine gute Entscheidung war und das noch viele Jahre Ärger machen wird!
Ich denke, das war eine kluge und weitsichtige Entscheidung. Die Probleme werden mit der Zeit kleiner, wenn nämlich mehr und mehr Programme und Bibliotheken Unicode intern verwenden und der Philosophie "decode early, encode late" folgen. Dann benötigt man das Default-Encoding gar nicht mehr.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Die ASCII-Lösung bricht zT leider auch alten Kode! (zB bei Filenamen mit Umlauten)
Das stimmt nicht. Dateinamen mit Umlauten funktionieren problemlos, wenn sie in Bytestrings abgespeichert werden. Falls sie in altem Kode
Meine Anmerkung oben war etwas zu kurz. Unten will ich Dir ein Beispiel nennen. Du hast recht, falls der Dateiname nur intern zum Öffnen, schreiben+lesen und dann close verwendet wird. In der Praxis kommt dazu aber sehr oft noch zB ein Print oder Log: - Bearbeitet gerade Datei "Name" etc. Diese Stellen brechen alle mit Unicode-Error ab. Module, die früher liefen.
Interessanterweise liefert Python solche Beispiele, also Kode, der jetzt abbricht, aber mit Python 1.5 lief, sogar mit:
Siehe etliche der Files in \Python22\Lib\lib-tk\
zB: tkFileDialog.py: Auswahl eines Files mit Umlaut -> unicode-crash wegen print tkSimpleDialog.py: crasht, wenn man Umlaute eingibt usw.
Diese Kodeteile müssten eigentlich alle überarbeitet werden.
In the face of ambiguity, refuse the temptation to guess.
Ein von Tims Regeln ;-)
Aber es ist Mehraufwand, wo es oft auch ohne gegangen wäre.
Mit "oft" meinst Du "bei den meisten Eingabedaten"? Das ist m.E. eine
Sorry, ich meinte damit: Oft weiss ich, das mein Script nur für einen kleinen Kreis in Deutschland interessant ist und er unter Win läuft und daher nur der Windows-Zeichensatz in Frage kommt. Der große Unicode- Rundumschlag wäre nicht nötig, ASCII + ein paar Umlaute reichten...
Errors should never pass silently.
Schon wieder Tim-Zen ;-)
Programme und Bibliotheken Unicode intern verwenden und der Philosophie "decode early, encode late" folgen. Dann benötigt man das Default-Encoding gar nicht mehr.
Naja, warten wir mal ab. Wie lange gibt es Unicode schon? Etwa 10 Jahre? Es sind immer noch sehr viele Programme nicht Unicode-tauglich.
Klaus Meyer km-news1@onlinehome.de writes:
Meine Anmerkung oben war etwas zu kurz. Unten will ich Dir ein Beispiel nennen. Du hast recht, falls der Dateiname nur intern zum Öffnen, schreiben+lesen und dann close verwendet wird. In der Praxis kommt dazu aber sehr oft noch zB ein Print oder Log: - Bearbeitet gerade Datei "Name" etc. Diese Stellen brechen alle mit Unicode-Error ab. Module, die früher liefen.
Ein Print oder Log, das früher lief, bricht jetzt mit einem Unicode-Error ab? Etwa so?
print dateiname
??? Das glaube ich nicht. Wenn dateiname ein Byte-String ist (wie er es ja sein muss, wenn es alter Code ist), dann funktioniert das print genausogut wie vorher. Was für ein Log Du verwendest, kann ich nur raten, aber ich nehme an, das müsste genauso weiter funktionieren.
zB: tkFileDialog.py: Auswahl eines Files mit Umlaut -> unicode-crash wegen print tkSimpleDialog.py: crasht, wenn man Umlaute eingibt usw.
Ah, tkFileDialog. Ja, das gibt es Unicode-Strings zurück. In Python 2.1 kann man die tatsächlich oft nicht an Datei-Funktionen übergeben. In Python 2.2 unter Windows schon - da wird nämlich das Plattform-Encoding für Dateinamen verwendet. Für Python 2.3 sollte solche Dateinamen sich in allen API-Funktionen verwenden lassen, auf Windows, Unix und Mac.
Die Verwendung des system default encoding wäre hier allerdings fatal gewesen: Auf Mac OS X *muss* ein solcher Dateiname UTF-8-kodiert werden, egal, was das Encoding der locale ist.
Diese Kodeteile müssten eigentlich alle überarbeitet werden.
In Python 2.3 sind sie es auch.
Sorry, ich meinte damit: Oft weiss ich, das mein Script nur für einen kleinen Kreis in Deutschland interessant ist und er unter Win läuft und daher nur der Windows-Zeichensatz in Frage kommt. Der große Unicode- Rundumschlag wäre nicht nötig, ASCII + ein paar Umlaute reichten...
Dann läßt sich ein solches Programm ja relativ leich anpassen: Man muss nur an ein paar Stellen die richtigen .encode- und .decode-Aufrufe einfügen, fertig.
Naja, warten wir mal ab. Wie lange gibt es Unicode schon? Etwa 10 Jahre?
Ungefähr, ja.
Es sind immer noch sehr viele Programme nicht Unicode-tauglich.
Das ist ja auch gar nicht erforderlich: Sehr viele Programme sollen auch gar nicht mit nicht-ASCII-Text arbeiten. Diejenigen, die es sollen, muss man halt anpassen.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
--On Montag, 5. Mai 2003 18:25 Uhr +0200 Klaus Meyer km-news1@onlinehome.de wrote:
Ganz einfach: GvR hat das entschieden und damit Basta :-)
Starkes Argument ;-) Nur wenig überzeugend... :-( Die ASCII-Lösung bricht zT leider auch alten Kode! (zB bei Filenamen mit Umlauten)
Genau. Ich persönlich hätte noch UTF-8 als Default akzeptiert: Es hat
UTF-8 bringt Dir auch nichts, weil Latin1 codierte Strings mit UTF8-8 als Default-Encoding nichts bringt. Latin1 ist *kein* Subset von UTF-8!
-aj
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Andreas Jung andreas@andreas-jung.com writes:
Genau. Ich persönlich hätte noch UTF-8 als Default akzeptiert: Es hat
UTF-8 bringt Dir auch nichts, weil Latin1 codierte Strings mit UTF8-8 als Default-Encoding nichts bringt. Latin1 ist *kein* Subset von UTF-8!
Klar hätte es mir was gebracht. Ich könnte
f=open("/tmp/bla","w") f.write(beliebiger_unicode_string)
ausführen, und müsste mich nicht um Encoding-Fehler kümmern. Wenn ich versehentlich einen nicht-UTF-8-String mit einem Unicode-String kombinierte, bekäme ich eine Exception (anders als bei Latin-1 als default encoding, aber genauso wie bei ASCII).
Allerdings wäre open(beliebiger_Unicode_string) ein ziemliches Desaster geworden, ungefähr genauso wie bei Latin-1, aber anders als bei ASCII.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (3)
-
Andreas Jung -
Klaus Meyer -
martin＠v.loewis.de