python code radikal verkuerzen

Du hast eine Idee für ein Projekt?
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

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). :)
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

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. :?: :?:
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Ja, in dem Fall schon.

Aber wenn du in deinen Quelltext u'ä' schreibst, wird es schwieriger :)
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
BlackJack

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.
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

Wollte damit sagen, dass

Code: Alles auswählen

# coding -*- utf-8- *- a
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 ?
BlackJack

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

Code: Alles auswählen

greeting = u'hällø'
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

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).
Benutzeravatar
mq
User
Beiträge: 124
Registriert: Samstag 1. Januar 2005, 19:14

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

@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.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

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.
TUFKAB – the user formerly known as blackbird
lunar

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...
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Weil Emacs r00le7?
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

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:

Code: Alles auswählen

läst = 'Hello world !'
print läst
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 !
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Das "u" ist kein Operator, sondern gehört zum Stringliteral dazu.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

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

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.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

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. :)
Antworten