kgm wrote:

Die Python-Unicde-Implementierung ist meiner Meinung nach mindestens "undurchsichtig". Ich gehe da aber lieber nicht weiter drauf ein, damit habe ich mich schon "unbeliebt" gemacht.

Das ist schade (beides: Dass Du glaubst, Dich "unbeliebt gemacht zu haben, und dass Du nicht erläutern willst, warum Du die Implementierung für "undurchsichtig" hälst). Die Unicode-Implementierung folgt einigen wenigen klaren Prinzipien: 1. Es gibt zwei String-Typen: und . Das sind völlig verschiedene Datentypen. 2. repräsentiert Bytes (Listen von Werten zwischen 0 und 255). 3. repräsentiert Zeichenketten (Buchstaben, Zahlen, Punkierung usw). 4. Zwischen und kann man umwandeln: a) str -> unicode: decoding b) unicode -> str: encoding Zur Umwandlung benötigt man stets und immer ein "Encoding". 5. Falls versucht wird, und ohne Konvertierung zu mischen, wird das "system default encoding" ('us-ascii') als Encoding verwendet. Diese Prinzipien halte ich nicht für undurchsichtig - deshalb die Bitte, näher zu erläutern. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

* Martin v. Loewis :

1. Es gibt zwei String-Typen: und . Das sind völlig verschiedene Datentypen.

Deshalb habe ich das nie Verstanden! Womöglich habe ich an den erklärenden Worten in Dokumentation und Büchern bisher immer vorbei gelesen. Falls es mir ab heute an einer Stelle auffallen sollte, werde ich die Autoren der Dokumentation um Verbesserung bitten, denn jetzt weiß ich, was den Texten immer gefehlt hat. Danke, Kai -- » kai weber _ http://www.glorybox.de _ icq 102024972 _ pgp 0x594D4132 _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

Olaf 'Ruebezahl' Radicke wrote:

Am Montag 29 Dezember 2003 00:54 schrieb Kai Weber:

...

* Martin v. Loewis :

...

1. Es gibt zwei String-Typen: und . Das sind völlig verschiedene Datentypen.

Deshalb habe ich das nie Verstanden!

...Wenn es dich tröstet - Ich habe es auch erst jetzt verstanden.

Ich habe jezt nicht den ganzen Thread durchgesucht, aber falls die Python-Unicode-FAQ bisher noch nicht erwaehnt wurde, dann ist es nun wirklich hoechste Zeit das nachzuholen! http://p-nand-q.com/python/unicode_faq.html -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de

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