kgm wrote:
Aber, fällt es Dir nicht auf, wie oft dazu Fragen auftauchen, auch in c.l.p? Da ja auch häufig von Dir dazu Antworten kommen, müßte es Dir auffallen ;-)
Das fällt mir schon auf. Ich glaube jedoch, dass das nicht daran liegt, dass die Python-Implementierung undurchsichtig ist, sondern dass vielen Entwickler einfach die "richtige" Modellvorstellung fehlt. Sie hatten bisher nur mit einer einzigen Zeichenkodierung zu tun, und haben deshalb das Phänomen "Zeichensätze" bisher gar nicht wahr genommen.
Das merkt man an Bemerkungen der Art, dass Byte-Strings "ASCII-Strings" genannt werden, selbst wenn dort nicht-ASCII-Zeichen vorkommen, die dann als "Sonderzeichen" bezeichnet werden, usw. Wenn das mentale Modell "es gibt mehr als einen Zeichensatz" sich verbreitet hat, ist auch die Python-Implementierung dieses Modells nicht mehr undurchsichtig.
Und wie sich da lange Diskussionen hin + her entwickeln, die aber eigentlich nicht zu eindeutigen Antworten führen.
Hmm. Wenn diejenigen, die Antworten, das Problem selbst nicht verstehen, kann das schon durchaus vorkommen. Immer häufiger lese ich aber die "richtigen" Antworten, die dann *immer* auch eindeutig sind.
Die Regeln sind, glaube ich, weitgehend klar. Du bist aber nicht auf die Ausnahmen+Sonderregeln eingegangen. Gerade das wäre interessant.
Bin ich. Es gibt die Sonderregel, dass man Bytestrings und Unicode-Strings "manchmal" kombinieren darf. Darüber hinaus gibt es in der Sprache keine Sonderregeln in Bezug auf Unicode.
Allerdings muss man zusätzlich noch wissen, welche Parametertypen und Rückgabetypen irgendwelche Funktionen der Bibliothek haben. Das muss man einfach auswendig lernen, so, wie man auch gelernt hat, dass
Integer + Integer ergibt Intger Integer + Float ergibt Float Liste + Liste ergibt Liste
Wie Du hier und da schon erwähnt hast, wurde dies+das aus Gründen der Rückwärtskompatibilität eingebaut, damit alte Scripte weiter laufen. (Stichworte: Tkinter, das mal Bytestrings, mal Unicode zurückgibt, Textdateien, die sich ohne Encoding-Angabe lesen/schreiben lassen.
Na ja - keine Regel der Sprache, sondern eben der Bibliothek. Die Bibliothek verändert sich auch stärker als die Sprache selbst. Gerade in Bezug auf Unicode ist zu erwarten, dass man in Zukunft Unicode-Strings an Funktionen übergeben darf, die heute nur Bytestrings akzeptieren; genauso, wie man heute an vielen Stellen long integers übergeben darf, wo vorher nur ints erlaubt waren.
Vermutlich noch andere Stellen, die ich noch nicht kenne (achja, was ist mit Filefunktion (open() usw.) bezgl. der Pfad/Filenamen mit Encoding? Irgendwas automatisch?)).
Gute Frage, siehe PEP 277. Seit Python 2.3 kann man auf nahezu allen Systemen Unicode-Dateinamen übergeben (an nahezu alle Funktionen - manche wurden vergessen). Dabei wird 1. Unter Win32 das Unicode-API verwendet, also erfolgt gar keine Konvertierung. Das bedeutet wiederum, dass a) unter NT+ (W2k, WXP, W2k3) die Dateien als Unicode-Folge auf dem NTFS abgelegt werden, und b) unter W9x die Namen in CP_ACP konvertiert werden (vom Betriebssystem) Damit kann man im Ergebnis unter NT+ beliebige Unicode-Dateinamen verwenden; unter W9x nur die, die in CP_ACP ("mbcs") unterstützt sind. 2. auf allen anderen Systemen der Dateiname mittels sys.getfilesystemencoding() kodiert. Dieses ergibt sich a) unter Max OS X als "UTF-8" b) unter Systemen, die nl_langinfo(CODESET) unterstützen, entsprechend der locale des Nutzers, und c) auf allen anderen Systemen aus dem system default encoding
In Python 2.2 war das etwas anders: Unter Win32 war das file system encoding immer "mbcs" (man hatte also nur 1b), und sonst war es immer system default encoding (also 2c); neu in 2.3 sind also 1a), 2a) und 2b).
Mein Wunsch wäre, eine Liste mit allen diesen Ausnahmen. Das wäre bestimmt sehr hilfreich. Wo genau wird was wegen Rückwärtskompatibel gemacht?
Wie gesagt: Das sind keine Ausnahmen. Ich könnte Deine Frage jetzt so interpretieren als: "Welche API-Funktionen verarbeiten Unicode-Strings, und welche geben Unicode-Strings zurück?"
Das würde allerdings eine ziemlich lange Liste werden...
Die Tkinter-Eigenheit führt zB auch in IDLE zu Bugs. Wenn Unicode doch so klar und "durchsichtig" ist, warum passieren dann sogar den Entwicklern der Sprache solche Fehler?
Aus zwei Gründen: Zum einen, weil man in Python immer testen muss, und IDLE offenbar zuwenig getestet wurde (in dieser Frage), zum anderen, weil es historischer Code ist, der früher intern nur Bytestrings verwendet hat, und nun intern Unicode-Strings verwenden sollte, das aber nicht einheitlich macht.
Andere Aspekte sind einfach keine Bugs: Das man beispielsweise im interaktiven Modus von IDLE keine Umlaute eingeben darf, ist kein IDLE-Bug. Vielmehr ist nicht klar, was die Umlaute an der Stelle bedeuten sollen, deshalb sind sie nicht erlaubt.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de