Das deutsche Python-Forum

Moment ,

Leonidas hat geschrieben:

Ja, einen Buchstaben zu verwenden der bei den meisten Tastaturen der Welt nicht vorhanden ist, ist hmm, eine innovative Idee. Vielleicht kann man aber auch noch ein paar Symbole aus APL einführen?

Ohne # coding -*- iso8859-1 -*- am Anfang eines Programmfiles bei mir läuft in Datenbank-Anwendungen gar nichts - ich brauche sie unbedingt, und zwar in jeder Datei eines Projekts (verwende allerdings 'mbcs'). Muss zugeben, dass ich noch immer zuviel herumdaddele in diesem Bereich, statt ihn einmal gründlich zu studieren. Ärgerlich überhaupt das Ganze - dass unicode(u's') gleich auf Errors läuft, macht Sonderzeichen heute wieder zu einem Problem, das sie 15 Jahre lang nicht waren.

Damit habe ich dann auch 'ä' für Objektnamen. Eine Rückübersetzung ist leicht: man muss nur "ä," "ä." und "ä)" durch replace-all ersetzen lassen - das trifft genau alle (eine entsprechende Objektnamen-Konvention - keine Enden auf 'ä' - ist nun wirklich nicht schwer einzuhalten).

'@' war wirklich nur ein Beispiel. Und wir sind ja einig darin, dass 'self' wichtig ist - deshalb will ich ja ein so auffälliges Zeichen (ist aber nicht wirklich wichtig).

joost hat geschrieben: Ohne # coding -*- iso8859-1 -*- am Anfang eines Programmfiles bei mir läuft in Datenbank-Anwendungen gar nichts - ich brauche sie unbedingt, und zwar in jeder Datei eines Projekts (verwende allerdings 'mbcs'). Muss zugeben, dass ich noch immer zuviel herumdaddele in diesem Bereich, statt ihn einmal gründlich zu studieren. Ärgerlich überhaupt das Ganze - dass unicode(u's') gleich auf Errors läuft, macht Sonderzeichen heute wieder zu einem Problem, das sie 15 Jahre lang nicht waren.

Woher soll denn Python wissen, ob dein Code mit Latin-1, UTF-8 oder Windows-1252 kodiert ist?

Würde man das Source-Encoding zwingend auf UTF-8 festschreiben wären die Windows-User beleidigt (es wird aber wohl in Py3k der Standard sein), die anderen Encodings wie Latin-1 sind sowieso international indiskutabel.

joost hat geschrieben:Ärgerlich überhaupt das Ganze - dass unicode(u's') gleich auf Errors läuft, macht Sonderzeichen heute wieder zu einem Problem, das sie 15 Jahre lang nicht waren.

Ja, aber vor 15 Jahren war internetionaler Datenaustausch ja auch nicht grad so sehr populär. Ich habe irgendwann entschieden, dass ich keine Lust mehr auf Encodings wie ISO-8859-1, MBCS und Co. habe und alles auf UTF-8 umgestellt.

joost hat geschrieben:Damit habe ich dann auch 'ä' für Objektnamen. Eine Rückübersetzung ist leicht: man muss nur "ä," "ä." und "ä)" durch replace-all ersetzen lassen - das trifft genau alle (eine entsprechende Objektnamen-Konvention - keine Enden auf 'ä' - ist nun wirklich nicht schwer einzuhalten).

Für dich. Aber wenn ein Amerikaner deinen Quellcode bekommt wird er dich verfluchen, weil er das ä nichteinmal eintippen kann. Von Ersetzen mal ganz zu schweigen. Ich finde, dass das einfach ein Fall ist, wo man es sich schwer macht, ohne dass es nötig ist.

joost hat geschrieben:'@' war wirklich nur ein Beispiel. Und wir sind ja einig darin, dass 'self' wichtig ist - deshalb will ich ja ein so auffälliges Zeichen (ist aber nicht wirklich wichtig).

Ruby benutzt @ zu so einem Zweck. Finde ich nicht lesbarer, da ich Line-Noise an meinen Variablennamen nicht so gerne sehe. YMMV.

Habe ich hier etwas mißverstanden ?

Schließlich nimmt der unicode-Constructor eine Code-Tabelle als zweites Argument, also stro = unicode('ä', 'iso8859-1'). Bisher nahm ich an, dass das - zumindest intern - unverzichtbar ist.

Ja, in dem Fall schon.

Aber wenn du in deinen Quelltext u'ä' schreibst, wird es schwieriger

Man kann 'ä' sowieso nicht als Namen in Python verwenden, es sei denn man nimmt eine Kodierung, die ein 'ä' in ASCII-Zeichen abbildet und die in Bezeichnern erlaubt sind. Sonst gibt's einen `SyntaxError`. Und soweit ich weiss hat sich Guido recht entschieden gegen die Aufhebung dieser Beschränkung ausgesprochen.

Die letzte grosse Umstellung gab's von DOS nach Windows, wovon auch heute noch "Nachwehen" in diversen Datenbeständen vorhanden sind. Ärgerlich sind aber auch heute Windowsdaten, die behaupten sie wären iso-8859-1 in Wirklichkeit aber cp1252 sind.

Wollte damit sagen, dass eigentlich fast eine no-op ist. Ich dachte, wir brauchen immer beides: Eine Auswahl des unicode-Formats und zusätzlich eine Code-Tabelle. Mißverständnis ?

Der "coding-Kommentar" ist dazu da, dass Python weiss, was es bei folgendem Quelltext tun soll:

Genau, das meinte ich ja. Das ist EINE Sache, die die coding-Zeile leistet. Sie leistet aber auch die andere: Code mit Sonderzeichen in Objektnamen wird interpretiert (habe mit meinen merkwürdigen ä-s für self durchaus einige Stunden ernsthaft programmiert, das waren wieder einmal allerhand Testläufe).

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.

@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.