Klaus Meyer
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