Das deutsche Python-Forum

@joost: Also ich bekomme in jedem Fall bei ein `SyntaxError` bei einem 'ä' in einem Namen. Wenn das bei Dir geht, dann ist das ein Bug.

lumax hat geschrieben:Wo wir gerade bei den Encoding-Deklarationen sind: Wieso hat sich eigentlich die Emacs-Syntax dafuer so durchgesetzt? Ich sehe da eigentlich nie andere Varianten, obwohl sie moeglich sind.

Sie schaut nett aus und mein Vim kann damit umgehen.

lumax hat geschrieben:Wo wir gerade bei den Encoding-Deklarationen sind: Wieso hat sich eigentlich die Emacs-Syntax dafuer so durchgesetzt? Ich sehe da eigentlich nie andere Varianten, obwohl sie moeglich sind.

Das ist eine globale Verschwörung von birkenfeld zur Vernichtung des VIM...

Weil Emacs r00le7?

Ja, BlackJack, ich heute auch. Erinnere mich offenbar falsch an den Versuch mit 'ä' - hab ein bißchen viel um die Ohren zur Zeit. In der idle kann man Code mit Sonderzeichen in der Source zum Laufen bringen, lässt sich unter Options/General einstellen. Das hier läuft dann: Aber nur wenn man KEINE coding-Zeile am Anfang des Programms hat. Heißt: Finger weg davon. Japaner können also ihren Code noch immer nicht in originärem Japanisch eingeben (finde eigentlich, dass sie das können sollten, und hatte das Vorhandensein einer Möglichkeit dazu eigentlich erwartet).

Damit hat die coding-Zeile also nur den Zweck, die Tabelle für den u-Operator einzustellen. Aufschlussreich !

Das "u" ist kein Operator, sondern gehört zum Stringliteral dazu.

Unter Operator verstehe ich eine Art Kürzel für eine function mit gleichzeitig veränderter Syntax wie x+y für __add__(x,y). Dann ist u sehr wohl ein Operator. Vielleicht ein etwas sehr Python-fixiertes Verständnis, aber nicht falsch. Oder ist die Zweistelligkeit miteintscheidend ? Dann wäre u halt ein Operator in verallgemeinertem Sinne.

Entscheidend ist, dass das 'u' nur eine Bedeutung für den Compiler hat und Teil der Syntax ist. Während das ``+`` zum Beispiel zur Laufzeit wirklich eine Funktion anstösst, gibt es das 'u' zur Laufzeit gar nicht mehr.

Nein, es ist ein integraler Bestandteil des Unicodeliterals, keine Anwendung einer Funktion.

Konsequenterweise müsstest du sonst auch den Punkt in `23.` einen Operator nennen.

Seh' ich ein. Als Operator müsste u ja auch auf Variable wirken können. Kann's nur auf Konstanten (und damit zur Laufzeit verschwunden sein). Ja, das ist etwas wirklich anderes, welches "Operator" zu nennen mindestens eine grobe Schlampigkeit ist.

Wollte damit sagen, dass

Code: Alles auswählen

# coding -*- utf-8 -*-

eigentlich fast eine no-op ist.

Weil in diesem Bereich so viel Verwirrung herrscht und wegen Drittlesern: Das war UNSINN. Um es noch einmal ganz klar festzustellen: Python verwendet intern die - abstrakten - Unicode-Codepoints. Das ist etwas ganz anderes als utf-8 und obige Codierungsanweisung insofern auch nie eine no-op. Ich finde hier eigentlich gute Beiträge zum Thema, z.B. http://www.python-forum.de/topic-5095.html. Der Satz daraus

Python verwendet als Basis Unicode!

wäre allerdings viel deutlicher, wenn das Wort 'codepoints' darin vorkäme. Jeder, der einmal Doku zum Thema sucht, ist sowieso schon auf diesen Begriff gestoßen und sollte ihn dann kennen. Sorry wegen meines Unsinns oben - ich hatte hier bisher dicke Tomaten auf den Augen.