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.
-- Mit freundlichen Grüßen Klaus Meyer :-) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de