Das deutsche Python-Forum

Costi hat geschrieben:wie wärs mit einer vereinfachung vom python-syntax:

So ziemlich alles was Du vorschlägst macht die Syntax nicht einfacher sondern komplizierter!

bei einer argumenten-uebergabe keine kommas, kein ":" nach if, for und while, wie in ruby wenn nicht noetig

Über den Doppelpunkt gab es in der englischsprachigen Newsgroup gerade eine Diskussion. Über den hat sich Guido am Anfang Gedanken gemacht. Der ist von ABC übernommen und die Entwickler von dieser Sprache haben empirische Tests durchgeführt ob Probanden Quelltext mit oder ohne den Doppelpunkt lesbarer und verständlicher finden. Bei Python wird ja bekanntlich grosser Wert auf Lesbarkeit gelegt, nun rate was das Ergebnis der Studie war.

"send "halo"" statt "send("halo")",

Äh ja, schön: noch mehr Sonderfälle. Insbesondere im Zusammenhang mit fehlenden Kommata zwischen Argumenten. Wie wird folgendes interpretiert: a b c d

Möglichkeiten:

a(b c d)
a(b(c d))
a(b(c(d))
a(b c(d))

Wie sieht das aus wenn noch Operatoren mit verschiedenen Prioritäten ins Spiel kommen?

wenn nich noetig bei bedingungsabfragen nur einen "=" statt zwei.

Wieder ein Sonderfall den man sich merken muss und der die Syntax verkompliziert. Zwei unterschiedliche Operatoren für die gleiche Funktionalität wobei der eine an anderer Stelle noch eine ganz andere Funktion hat!? Argh! Welchem Anfänger möchte man Python dann noch als einfache, in sich konsistente Sprache empfehlen!?

Und bei allen Änderungen die Du vorschlägst musst Du noch eine technische Besonderheit beachten: Egal was für Python3K umgesetzt wird, die Syntax soll auf jeden Fall von einem LL(1)-Parser verstanden werden können.

der interpreter wuerde in python selbst geschrieben sein und muesste nur python-scripts parsen und ausführen

So ein ähnlicher Vorschlag wurde Dir ja schon gemacht: Nimm Lisp oder Scheme. Sehr viel einfacher kann man eine Syntax nicht machen. Bigloo ist ein ganz netter Scheme-Compiler.

Wenn es etwas mit Python zu tun haben soll, dann kannst Du einen Blick auf Noodle werfen.

Ansonsten ist Io noch eine sehr interessante Sprache mit ziemlich wenig Syntax und extrem wenigen Schlüsselworten. Ist aber noch jung und die APIs sind noch im Fluss.

Und dann fehlt noch der obligatorische Hinweis auf den Griechen-Compiler: http://students.ceid.upatras.gr/~sxanth/pyvm/ und PyPy.

Hi,

Python-Syntax ist doch toll ! So wie sie ist, geht das geradezu in den Sehnerv hinein (hatte nach einem dreiviertel Jahr schon Momente, in denen ein Blick auf einen mit Code vollen Bildschirm mir sagte: Eh, da stimmt was nicht).

Also: Auf gar keinen Fall!

Ein Syntax-Fehler, der mir immer wieder noch unterläuft:
Verstehe übrigens nicht, warum es diese Klammern nicht gibt - schließlich ist eine Klasse ein callable.

Außerdem verwende ich 'self' nicht mehr, frisst zuviel Platz. Ist im Moment 'q' , am besten wäre aber ein freies deutliches Zeichen wie @ es ist - wenn ich es recht sehe, müsste man dafür aber den Parser ändern. Ein paar Stunden lang fand ich 'ä' im Sinne von 'äh' ganz lustig und insofern echt pythonisch, dann aber doch nicht mehr.

Ein zweites, das mich ein bisschen nervt: Das Auspacken von 1-Tupeln ist eigentlich nur durch workarounds wie (x,)[0] möglich. Kann aber nicht anders gehen: y = (x,) für Auspacken wäre völlig gegen das typing by assignment. Man müßte für eine solche Vereinheitlichung einen Auspack-Operator erfinden wie: x,y,z = ,(1,2,3) oder sowas. Wäre für Anfänger in der Sprache und die allgemeine Lesbarkeit gar nicht schlecht, x = ,() würde dann 'None' zuweisen.

Viel Spaß !

joost hat geschrieben:Ein Syntax-Fehler, der mir immer wieder noch unterläuft:

Code: Alles auswählen

class Beispiel():

Mit Python2.5 und höher nicht mehr.

joost hat geschrieben:Ein Syntax-Fehler, der mir immer wieder noch unterläuft:

Code: Alles auswählen

class Beispiel():

Verstehe übrigens nicht, warum es diese Klammern nicht gibt - schließlich ist eine Klasse ein callable.

Davon abgesehen dass es nicht darum geht die Klasse aufzurufen (schlicsslich ruft def funktion() die Funktion auch nicht auf) ist dies in Python 2.5 möglich - aus Konsistenzgründen. Inzwischen schreibe ich aber in der Regel sowieso ``class Klassenname(object)``.

joost hat geschrieben:Außerdem verwende ich 'self' nicht mehr, frisst zuviel Platz. Ist im Moment 'q' , am besten wäre aber ein freies deutliches Zeichen wie @ es ist - wenn ich es recht sehe, müsste man dafür aber den Parser ändern.

Deinen Code möchte ich echt nicht sehen müssen. Das ``self`` ist aus guten Grund da - es erfüllt die gleichen Funktion wie das von dir vorgeschlagene @: ein Name bei dem sofort klar ist, was an ihn gebunden ist. Außerdem ist @ schon für die Dekoratoren reserviert - ob das eine gute Idee war ist natürlich eine andere Frage. Mir gefallen die anderen Dekorator-Syntaxvorschläge besser.

joost hat geschrieben:Ein paar Stunden lang fand ich 'ä' im Sinne von 'äh' ganz lustig und insofern echt pythonisch, dann aber doch nicht mehr.

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?

joost hat geschrieben:Man müßte für eine solche Vereinheitlichung einen Auspack-Operator erfinden wie: x,y,z = ,(1,2,3) oder sowas. Wäre für Anfänger in der Sprache und die allgemeine Lesbarkeit gar nicht schlecht, x = ,() würde dann 'None' zuweisen.

Kannst du nicht blackbirds Unpack-Operator ``,=``?

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 !