RFC - Einrückung (off-side rule) vs Blockendezeichen

[Tütenflieger]

Ich bin Neuling in der Programmiersprache Python, doch der folgende Vorschlag kann vermutlich nur von einem Neuling gemacht werden!

Sprachelement von Python ist die Einrückung, das ist für für C-, Pascal- oder VB-Programmierer merkwürdig aber erlernbar.

Durch die Verwendung verschiedener Editoren und einen Mix aus Leerzeichen und Tabulatoren können aber lästige Fehler auftreten, die es bei Sprachen mit Blockendezeichen nicht gibt.

Wie kann man eine bestehende Programmiersprache ändern, ohne dabei alles kaputt zu machen? Dazu mein Vorschlag als "Request for Comments", möglich, dass ich / wir die große Python Community überzeugen.

1. Blockendekennzeichen "#"
Das #-Zeichen kennzeichnet eigentlich einen Kommentar, mit einer kleinen Regel könnte daraus ein Blockendekennzeichen werden
[beliebig viele Whitespaces] + # + Zeilenumbruch
oder
[beliebig viele Whitespaces] + # + Leerzeichen + # + Kommentar
oder
[beliebig viele Whitespaces] + # + EOF

Also in Worten: "Ein # schließt einen Block ab, wenn danach kein weiterer Text steht."
und: "Ein #-Blockende kann mit einem weiteren # kommentiert werden."


2. Compilerdirektive "# Ends"
Im Kopf einer Py-Datei muss dem Compiler bekannt gemacht werden, dass dieses Script Blockendekennzeichen nutzt, das "# Ends" könnte so ein Kennzeichen sein.


Vorteile dieser Lösung
Da sich alle Vorschläge innerhalb der Kommentarregel bewegen,
tangiert keiner meiner Vorschläge in irgendeiner Weise bestehenden Python-Code.
Alter und "neuer" Code können mit dem selben Interpreter ausgeführt werden.
Editoren (IDEs) könnten am #-Blockende automatisch richtige Einrückungen generieren und korrigieren und so die Abwärtskompatibilität zum bestehenden Sprachstandard wahren.

Beispiel:
klassisch

Code: Alles auswählen

def fakultaet(x):
    if x > 1:
        return x * fakultaet(x - 1)
        eineWeitereAnweisung
        undNochEineAnweisung
    else:
        return 1

Und so sieht das aus, wenn ich das Code-Beispiel nicht als "code" formatiere:
def fakultaet(x):
if x > 1:
return x * fakultaet(x - 1)
eineWeitereAnweisung
undNochEineAnweisung
else:
return 1
# Und schon funktioniert das Programm nicht mehr!

mit #-Ends (und ein wenig Kommentar)

Code: Alles auswählen

def fakultaet(x):
    if x > 1:
        return x * fakultaet(x - 1)
        eineWeitereAnweisung
        undNochEineAnweisung
        #
    else:
        return 1
        # Dieses '#' wäre kein Blockende, da hinter dem Zeichen noch Text steht
        # Ein Blockende wäre hier auch nicht nötig, da der Block nur aus einer Zeile besteht.
        # Das if ist in diesem Fall auch ausreichend über "else:" abgeschlossen.
# # Beendet die Fakultätfunktion - Und so sähe ein kommentiertes Blockende-Zeichen aus.

[sparrow]

Klingt nach Nonsens.
Wenn man Schon Blöcke kennzeichnen will kann man auch Klammern nehmen.
Und wenn man Klammern möchte kann man sich ja mit Programmiersprachen beschäftigen die die haben.

Außerdem gehört das mmn eher in den Bereich Off-Topic

Gruß
sparrow

[Xynon1]

Durch die Verwendung verschiedener Editoren und einen Mix aus Leerzeichen und Tabulatoren können aber lästige Fehler auftreten, die es bei Sprachen mit Blockendezeichen nicht gibt.

Aus meinem Blickwinkel, finde ich es nun nicht besonders schwer einen Editor zu wählen, welcher so eingestellt werden kann, das er immer ein Tab durch exakt 4 Leerzeichen ersetzt.

Wenn durch irgendetwas das doch mal schief geht, gibt es immer noch "tabnanny". Wo siehst du da eigentlich die Problematik?

[pudeldestodes]

Oder man ruft den Interpreter standardmäßig mit dem -t oder sogar -tt Parameter auf, der einen vor solchen Inkonsistenzen warnt.

[b.esser-wisser]

Außerdem musst du Code in jeder Sprache korrekt einrücken, wenn den jemand anders lesen soll (und python kennt sehr wohl 'from __future__ import braces').

[BlackJack]

@Tütenflieger: Du bist nicht der Erste mit so einer Idee. Was zu dem von b.esser-wisser erwähnten `__future__`-Import geführt hat. Kannst ja mal überlegen wieviel Energie Du also da rein stecken möchtest.

Bei dem einzelnen '#' sähe ich übrigens das Problem, dass es bestehende Quelltexte gibt, bei denen "leere" Kommentarzeilen als Abgrenzungen oder Abstandhalter vorkommen. Also zum Beispiel:

Code: Alles auswählen

for parrot in items:
    # 
    # Here we apply `spam()` to every single parrot
    # because...
    # 
    spam(parrot)

Während die Idee, dass Einrückung von der Programmiersprache berücksichtigt wird, für C-, Pascal-, oder VB-Programmierer merkwürdig sein mag, so ist es das Einrücken selber eigentlich nicht. Die müssen sich also nicht das Einrücken angewöhnen, sondern nur die Klammern beziehungsweise Endschlüsselwörter abgewöhnen. Falls das schwer fällt, können sie ja übergangsweise ``# {``/``# }`` oder ``# end if`` usw. in den Quelltext schreiben. Bis sie dann ohne Stützräder fahren können.

[Rebecca]

Ist schon erster April?

[Tütenflieger]

Da gibt es ja doch eine schnelle Resonanz, wenn auch keiner von meiner Idee begeistert zu sein scheint.
BlackJack schlägt vor, mir mit #{ und #} "Stützräder zu basteln, dagegen habe ich überhaupt nichts, besser Stützräder als blaue Flecken, doch das Problem mit falschen Einrückungen können die leider nicht lösen und ich hatte tatsächlich das Problem, dass ich ein Script mit zwei verschiedenen Editoren geöffnet hatte und es danach plötzlich nicht mehr ging, obwohl ich optisch keinen Unterschied ausmachen konnte und das fand ich doch ziemlich merkwürdig.

Wenn es mit _future_import braces bereits eine Lösung für "off-side rules Verweigerer" gibt, na prima. Das kannte ich noch nicht, hab dafür aber auf die Schnelle auch noch keine Dokumentation gefunden.

Allen Vielen Dank.

[sparrow]

Wenn es mit _future_import braces bereits eine Lösung für "off-side rules Verweigerer" gibt, na prima. Das kannte ich noch nicht, hab dafür aber auf die Schnelle auch noch keine Dokumentation gefunden.

Das ist selbstdokumentierend

[Xynon1]

...hatte tatsächlich das Problem, dass ich ein Script mit zwei verschiedenen Editoren geöffnet hatte und es danach plötzlich nicht mehr ging, obwohl ich optisch keinen Unterschied ausmachen konnte und das fand ich doch ziemlich merkwürdig.

Dafür gibt es wie ich oben schon erwähnt habe "tabnanny". Selbst IDLE stellt eine Funktion "Untabify Region" dafür. Wenn also tatsächlich durch die Schussligkeit des Programmierers sowas ergeben sollte, kann man solche Funktionen nutzen.

[BlackJack]

@Tütenflieger: Die ``# {``/``# }``-Kommentare alleine stellen noch keine Lösung dar, aber es lässt sich leicht ein Programm schreiben dass die Einrückung in so einer Datei korrigiert wenn die Kommentare konsequent benutzt werden.

Wie schon gesagt bist Du nicht der erste, der mit so einer Idee kommt. Hier ist zum Beispiel eine Diskussion von 1994(!): http://groups.google.com/group/comp.lan ... f111ae7ec1

Vielleicht um die "Gewichte" der Positionen in der Diskussion besser einschätzen zu können: Guido van Rossum und Tim Peters sind Schwergewichte weil Python "core developer" und im Fall von Guido der Erfinder der Sprache.

Bis jetzt hat es seit 1994 -- also in fast 17 Jahren -- noch niemand geschafft Argumente zu bringen, welche die "core developer" oder Guido überzeugen konnten. Alles was da bisher an Implementierung heraus kam, war das hier:

Code: Alles auswählen

In [247]: from __future__ import braces
------------------------------------------------------------
SyntaxError: not a chance (<ipython console>, line 1)

In vielen dieser Diskussionen kamen auch oft Wortmeldungen von Leuten die gesagt haben, dass sie am Anfang auch mit irgendwelchen Problemen gerechnet haben, in der Praxis aber keine hatten.

Das mit den gemischten Tabs/Spaces wird im Style Guide (PEP8) angesprochen und dort wird auch empfohlen `-t` oder `-tt` zu benutzen um das zu verhindern beziehungsweise "sichtbar" zu machen.

[pudeldestodes]

Wieso ist das Standardverhalten eigentlich so, dass der Interpreter gemischte Tab-/Leerzeichennutzung in einer Datei überhaupt zulässt? -tt erscheint mir eigentlich ziemlich sinnvoll und das hier beschriebene Problem wäre gar nicht erst aufgetaucht.

[Leonidas]

Vermutlich weil als ``-tt`` erdacht wurde, dachte man dass zu viel Quelltext dadurch kaputtgeht.

Tütenflieger, was ist jetzt genau dein Problem? Hast du ein Problem mit den Editoren oder dass es zu viel Umgewöhnung ist, die Blöcke implizit zu kennzeichnen? Als ich mit Python angefangen habe, haben viele Programmierer noch über diese Art der Blockmarkierung noch die Nase gerümpft, heutzutage wundert das keinen mehr und die meisten findens Praktisch. In der Praxis macht das auch keine Probleme.

[Darii]

Durch die Verwendung verschiedener Editoren und einen Mix aus Leerzeichen und Tabulatoren können aber lästige Fehler auftreten, die es bei Sprachen mit Blockendezeichen nicht gibt.

Das ist kein Problem. Das einzige Problematische daran ist, dass man keine/(oder nur umständlich) Ausdrücke basteln kann, die weitere Anweisungsblöcke (if, while, etc...) enthalten. So könnte man, wenn man wollte, in lambda nur schwerlich Unterstützung für Schleifen etc. einbauen.

[Tütenflieger]

Tütenflieger, was ist jetzt genau dein Problem? Hast du ein Problem mit den Editoren oder dass es zu viel Umgewöhnung ist, die Blöcke implizit zu kennzeichnen? Als ich mit Python angefangen habe, haben viele Programmierer noch über diese Art der Blockmarkierung noch die Nase gerümpft, heutzutage wundert das keinen mehr und die meisten findens Praktisch. In der Praxis macht das auch keine Probleme.

Mein Problem, nun jede Programmiersprache hat ihre Eigenheiten und persönliche Geschmäcker gibt es auch, da muss man halt lernen.
Ich habe mich halt bisher in Programmiersprachen bewegt, die Blöcke kennzeichnen, ob mit "{}" oder "end" oder ".", eine Sprache, die Einrückungen dafür benutzt fand ich zunächst einfach merkwürdig, hab mich aber darauf eingelassen. Geärgert hat mich das dann erst, als ich mein erstes kleines Testprogramm mit unterschiedlichen Editoren geöffnet hatte und es plötzlich nicht mehr funktionierte.
Zur Erklärung, ich hatte mich einfach intuitiv auf die Sprache Eingelassen, ohne zuvor ein Handbuch zu lesen, also einfach mal ein bestehendes Skript überarbeitet, getestet, verändert und wieder getestet. Alles funktionierte prima, bis ich etwas gemacht habe, an dem ich optisch keinen Unterschied feststellen konnte.
Und auch zur Erklärung: Ich bin in Textverarbeitungen kein Fan von zig Leerzeichen, sondern empfehle da eigentlich immer Tabs zu benutzen - gut, das hier ist keine Textdokument, sondern ein Codescript, ich erkläre nur, wie ich dazu gekommen bin, mit Tabs nach meinem Geschmack das Script zu "verschönern" und das ging leider nach hinten los.

Was ich versucht habe zu beschreiben, ist ein Weg, wie man ohne die Sprache Python signifikant zu verändern, eine Blockende implementieren könnte.
Meine Lösung funktioniert ja auch ganz unabhängig nur im Editor, wenn dieser spätestens beim Speichern anhand der Blockende die Einrückungen korrigiert. Das kann dann halt nicht jeder Editor, sondern nur meiner (den es noch nicht gibt).
Ich werde sicher keinen eigenen Python-Interpreter programmieren, doch wenn's gefällt, dann könnte das ja als Alternative eingebaut werden. (Haut mich nicht wieder, es war nur ne Idee, die offensichtlich noch niemand überzeugt hat.)

Wie BlackJack schon erwähnte bin ich mit dieser Idee aber nicht alleine [1.April (?) nö]
http://groups.google.com/group/comp.lan ... f111ae7ec1
Selbst die Idee "#" zu benutzen wurde hier ja schon so ähnlich "# End" beschrieben.
Die Sache mit den leeren # zum Abstand halten [BlackJack] ist aber wirklich ein Argument und man müsste an entsprechender Stelle prüfen, ob damit leere Blöcke entstehen und ob das Probleme bereitet.

====

Also lasst's euch nicht verdrießen, dass ein Anfänger wieder mal alles besser wissen wollte.
Tschüß