[Python-de] Unicode, warum ASCII als default, warum nicht Latin-1 ???

Martin v. Löwis martin at v.loewis.de
Mon May 5 23:27:27 EDT 2003


Klaus Meyer <km-news1 at 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




More information about the Python-de mailing list