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