else: invalid syntax

[Kev G. (kev_g)]

Hey kann mir jemand sagen warum der fehler dauernd kommt hab schon ewig 
rumprobiert :


from tkinter import *


class Verkaufen(Button):
    def verkaufen (self):
        class MyButton (Button):
            def aktion(self):
                artnr = eingabe1.get()
                f = open('C:\dateien\sortiment.txt', 'r')
                liste = f.readlines()
                f.close()

                geloescht = False

                for i in range(len(liste)):
                    if liste[i] == artnr+"\n":
                        f = open('C:\dateien\sortiment.txt', 'w')
                        liste = liste[:i] + liste [i+6:]
                        for linie in liste:
                            f.write(linie)
                            geloescht = True
                            break
                f.close()
                f.destroy()
if geloescht:
    fenster2 = Tk()
    fenster2.geometry("300x100")
    fenster2.title("Auto verkauft!")
    rahmen2 = Frame(fenster2, relief="ridge", borderwidth=5)
    rahmen2.pack(fill="both", expand = 1)

label2 = Label(rahmen2, text="Auto aus dem Sortiment entfernt!")
label2.pack(expand = 1)
button2 = Button(rahmen2, text="OK", command = fenster2.destroy)
button2.pack(side = "bottom", pady = 5)
fenster2.mainloop()

####Zeile39####
else:
    fenster2 = Tk()
    fenster2.geometry("300x100")
    fenster2.title("Warnung!")
    rahmen2 = Frame(fenster2, relief="ridge", borderwidth=5)
    rahmen2.pack(fill="both", expand = 1)
    label2 = Label(rahmen2, text="Artikelnummer nicht gefunden!")
    label2.pack(expand=1)
    button2 = Button(rahmen2, text="OK", command=fenster2.destroy)
    button2.pack(side = "bottom", pady = 5)
    fenster2.mainloop()

fenster = Tk()
fenster.geometry("500x400")
fenster.title("Fahrzeug löschen")
rahmen = Frame(fenster, relief="ridge", borderwidth=5)
rahmen.pack(fill="both", expand = 1)
label = Label(rahmen, text = "Welches Auto möchten Sie verkaufen?")
label.config(font=("Arial", 14, "bold"))
label.place(x = 50, y = 10)
label1 = Label(rahmen, text = "Artikelnummer:")
label1.place(x = 100, y = 100)
eingabe1 = Entry(rahmen, bd = 2, width = 22)
eingabe1.place(x =200, y = 100)
button = MyButton(rahmen,text="Eingabe")
button["command"] = button.aktion
button.place(x = 180, y = 220)


fenster.mainloop()




Fehler:
line 39
    else:
    ^
SyntaxError: invalid syntax

[NichtWichtig (Gast)]

dem else fehlt das if

[Vancouver (Gast)]

Weil die Zeilen ab
label2 = ...
nicht eingerückt sind und das vorherige "if" damit schon zuende ist. Das 
"else" ist damit herrenlos.
Da schlägt der einzige echte Schwachpunkt von Python mal wieder zu. Ein 
unsichtbares Zeichen als funktionsrelevantes Syntaxelement zu verwendet, 
ist einfach keine gute Idee

[Jim M. (turboj)]

Vancouver schrieb:
> Ein
> unsichtbares Zeichen als funktionsrelevantes Syntaxelement zu verwendet,
> ist einfach keine gute Idee

Da bin ich anderer Meinung.

Bei C hätte man ewig gebraucht um bei ähnlicher Fehlermeldung die 
Klammern zu zählen.

Hier bei Python erkennt man den Anfängerfehler sofort...

OP sollte sich mal die Anfänger Tutorials zu Python anschauen, Copy & 
Paste funktioniert schon bei einfachen Problemen nicht mehr.

[c-hater (Gast)]

Jim M. schrieb:

> Vancouver schrieb:
>> Ein
>> unsichtbares Zeichen als funktionsrelevantes Syntaxelement zu verwendet,
>> ist einfach keine gute Idee
>
> Da bin ich anderer Meinung.

Aber ich (und jeder erfahrene Programmierer) sieht das genau so wie 
Vancouver. Und allein schon das konkrete Beispiel zeigt nur zu deutlich, 
dass all diese erfahrenen Leute völlig richtig liegen...

Falls dir das nicht selber aufgefallen ist ist...

[Heiner (Gast)]

Jim M. schrieb:
> Bei C hätte man ewig gebraucht um bei ähnlicher Fehlermeldung die
> Klammern zu zählen.

Jeder anständige Editor unterstützt dich bei dieser "unmöglichen" 
Aufgabe. Ob du nur eine Syntaxhervorhebung willst, einen Marker, der die 
falsche Klammerung anzeigt, oder die schließende Klammer gleich 
automatisch mit der öffnenden Klammer eingefügt werden soll, ist 
Geschmackssache.

Nur gilt das eben auch für die Einrückung in Python: Jeden vernünftigen 
Editor kann man so einstellen, dass das oben geschilderte Ergebnis nicht 
versehentlich entsteht.

Und natürlich sind nicht nur die Zeilen ab label2 = ... falsch 
eingerückt, sondern bereits die Zeilen ab if ..., denn offensichtlich 
gehört das alles doch zur Methode "aktion" und braucht daher 4 
zusätzliche Einrückungsebenen.

kev_g, nochmal ein Versuch: Mach ein paar Schritte zurück und eigne dir 
die Grundlagen von Python an. Du bleibst sonst dauerhaft an solchen 
Kleinigkeiten hängen.

[Kev G. (kev_g)]

Das wusste ich bereits aber wenn ich das alles einrücke so wie es sich 
eigentlich gehört kommt dass alles ab label2 unnötig eingerückt ist.

[MaWIn (Gast)]

Kev G. schrieb:
> kommt dass alles ab label2 unnötig eingerückt ist.

Tab und space gemischt?

[Kev G. (kev_g)]

Dachte ich auch aber nein hab scho so viel rumprobiert...






 label2.pack(expand = 1)
    ^
IndentationError: unexpected indent

[MaWIn (Gast)]

Kev G. schrieb:
> IndentationError: unexpected indent

Das ist aber der typische Fehler, bei gemischten Tabs + 4-er-spaces.
Mache einfach mal ein suchen-ersetzen mit regex zu \t

[Kev G. (kev_g)]

Hab ich auch schon ^^
Das interessant ist wenn ich alles einrücke dann kommt der Fehler 
nichtmehr aber es bildet sich dann logischerweise ein Teufelskreis an 
Fehlern

[Heiner (Gast)]

Ok, und wie sieht der Code mit dem "Teufelskreis" aus? Kannst du den 
bitte als Datei anhängen, nicht in einen Beitrag einkopieren, damit die 
Einrückungen ganz sicher exakt so erhalten bleiben, wie sie bei dir 
waren?

[Kev G. (kev_g)]

Also die Einrückung passt auf jeden Fall dass würde man sonst ja sehen 
an der Linie links neben dem Code..

wenn ich jetzt das einrücke so wies es dem programm lieb ist kommt dass 
ich sell und jenes einrücken muss... zuerst quasi die zeilen die unter 
label2 stehen alle, dann logischerweise else:invalid syntax


 hab die datei angehängt

[Heiner (Gast)]

Kev G. schrieb:
> Also die Einrückung passt auf jeden Fall

... nicht. :)

Das ganze Zeug ab if geloescht muss eine zusätzliche Ebene eingerückt 
werden. Ich würde vermuten, dass ab fenster = Tk() gar nicht mehr 
eingerückt wird.

[Kev G. (kev_g)]

Das ist das Ding denn wenn ich das mache schließt sich der Kreis undzwar 
kommt dann das hier:

label2.pack(expand=1)
    ^
IndentationError: unexpected indent


Übrigens DANKE für die Hilfe ich weiß ich bin noch ein Anfänger aber ich 
habe das Programm fast fertig und wills einfach hinbekommen ^^´

[Jens G. (jensig)]

Ich denke, das liegt an den vielen Spaces in den Leerzeilen ...

[Kev G. (kev_g)]

Ne hab es auf ein Minimum reduziert und der Fehler kommt trotzdem :/

[hidden symbol (Gast)]

Vancouver schrieb:
> Ein
> unsichtbares Zeichen als funktionsrelevantes Syntaxelement zu verwendet,
> ist einfach keine gute Idee

und dann

MaWIn schrieb:
> Tab und space gemischt?
MaWIn schrieb:
> typische Fehler, bei gemischten Tabs + 4-er-spaces
Jens G. schrieb:
> das liegt an den vielen Spaces in den Leerzeilen

Ich bin dann mal bei Vancouver ;-)

[MaWIn (Gast)]

Man sieht doch eindeutig und unmissverständlich, dass Zeile 32 falsch 
eingerückt ist.
https://www.mikrocontroller.net/attachment/highlight/498254

Willst du uns hier veralbern?

[Dussel (Gast)]

Python ist halt nur ein halbfertiger Entwicklungsschritt. Zum Ziel 
gebracht haben es dann 2002 Brady und Morris mit der Entwicklung von 
Whitespace. Da muss man sich nicht mehr mit so willkürlichen und 
kryptischen Zeichen wie zum Beispiel Buchstaben und Zahlen rumschlagen. 
Und man wird von Anfang an zu Sorgfalt, nicht nur im Hinblick auf 
Einrückung, erzogen, weil Fehler schwer finden sind.

[GH-Mörtel (Gast)]

Dussel schrieb:

> Python ist halt nur ein halbfertiger Entwicklungsschritt.

> ...

> Da muss man sich nicht mehr mit so willkürlichen und
> kryptischen Zeichen wie zum Beispiel Buchstaben und Zahlen rumschlagen.
> Und man wird von Anfang an zu Sorgfalt, nicht nur im Hinblick auf
> Einrückung, erzogen, weil Fehler schwer finden sind.

Und nicht vergessen: Python ist eine unbedeutende Sprache und findet 
seit nunmehr 30 Jahren keinen Anklang in der Entwicklergemeinde.

https://www.heise.de/developer/meldung/Python-schreibt-Geschichte-Platz-2-im-Programmiersprachen-Ranking-4673726.html

[Jemand (Gast)]

Kev G. schrieb:
> from tkinter import *
>
> class Verkaufen(Button):
>     def verkaufen (self):
>         class MyButton (Button):

Was wird das denn für ein Unsinn? Eine Klasse, die von Button erbt, mit 
einer Methode, in der eine weitere Klasse deklariert wird, die ebenfalls 
von Button erbt? Was soll das werden?

>                 f = open('C:\dateien\sortiment.txt', 'r')
>                 liste = f.readlines()
>                 f.close()

with open('C:\dateien\sortiment.txt', 'r') as ifh:
    liste = ifh.readlines()

> if geloescht:
>     fenster2 = Tk()
> [...]
> label2 = Label(rahmen2, text="Auto aus dem Sortiment entfernt!")
> [...]
> fenster2.mainloop()
>
> ####Zeile39####
> else:

Einrückung!

>     fenster2 = Tk()
> [...]
> fenster = Tk()

Drei Root-Fenster?  Rly? Wozu gibt es eigentlich die Klasse 
tkinter.Toplevel?

Kev, ehrlich: Dein Code ist so wirr, daß ich nicht einmal ansatzweise 
erkennen kann, was er eigentlich tun soll. Anscheinend irgendwas mit 
Autos, danach verlassen mich die Geister. BITTE hör' auf, Dich an 
irgendwelchen GUI-Programmen zu versuchen, bevor Du die absoluten 
Grundlagen verstanden hast. Einen Fahranfänger schickt man ja auch nicht 
in der ersten Fahrstunde zur Hauptverkehrszeit in einem doppelstäckigen 
Bus über den Trafalgar Square.

Wenn Du die Grundlagen verstanden hast -- und zwar zu allererst 
angefangen mit der Syntax -- kannst Du Dich an die Grundlagen der 
Objektorientierung begeben. Nicht umgekehrt. Hier [1] hat Sheeva mal ein 
paar Grundlagen der OOP beschrieben und die Rationale erläutert, aber 
auch das liest Du bitte erst, wenn Du die Grundlagen -- Syntax, Scope, 
Datentypen, Funktionen, Schleifen, Verzweigungen und diese Dinge -- 
verstanden hast und sicher (!) beherrschst. Ansonsten tätest Du gut 
daran, mal die anderen Ratschläge zu befolgen, die Sheeva Dir ganz 
persönlich gegeben hat: [2] und [3]. Ansonsten wird das nämlich nie was, 
trust me on this one.

[1] https://en.mikrocontroller.net/topic/512152#6572922
[2] Beitrag "Re: Frame wird nicht erkannt (Python3.0)"
[3] Beitrag "Re: Variable nicht definiert"

[Jemand (Gast)]

c-hater schrieb:
> Aber ich (und jeder erfahrene Programmierer) sieht das genau so wie
> Vancouver.

Das ist erstens falsch -- sonst wäre Python nicht mittlerweile die 
nachweislich verbreitetste und beliebteste Skriptsprache der Welt -- und 
zweitens ein argumentum ad populum, einer seriösen Diskussion also 
ohnehin unwürdig. Und das ausgerechnet Du von einem erfahrenen 
Programmierer weit entfernt bist, sieht ein kluger Leser ja schon an dem 
Nickname, den Du Dir gegeben hast.

[Kev G. (kev_g)]

Eine Antwort zu meinem Problem statt dauernde Verachtung wäre hilfreich 
gewesen aber naja bin ja im Internet

[MaWin (Gast)]

Kev G. schrieb:
> Eine Antwort zu meinem Problem

Dein Problem wurde schon lange beantwortet.
Die Einrückungen stimmen nicht.

[Kev G. (kev_g)]

Die Einrücken in Zeile 32 hab ich schon behoben
dann kommt das geloescht nicht definiert ist

[Jens G. (jensig)]

>Die Einrücken in Zeile 32 hab ich schon behoben

Zeig mal (per hochgeladener Datei), was jetzt aktuell zur Diskussion 
steht  ...

[MaWin (Gast)]

Kev G. schrieb:
> Die Einrücken in Zeile 32 hab ich schon behoben
> dann kommt das geloescht nicht definiert ist

            def aktion(self):
                geloescht = False
            if geloescht:

Es ist ja in dem Scope, wo du es abfragst, auch nicht definiert.

Nimm dir ein Python-Buch und lies es.

[Kev G. (kev_g)]

MIt dem Buch schreibe ich das Programm aber Danke

[hidden symbol (Gast)]

Jemand schrieb:
> wäre Python nicht mittlerweile die
> nachweislich verbreitetste und beliebteste Skriptsprache der Welt

TikTok ist auch weit verbreitet. Und braucht s einer?

MaWin schrieb:
> Es ist ja in dem Scope, wo du es abfragst, auch nicht definiert.
> Nimm dir ein Python-Buch und lies es.

Und die nächste Abhängigkeit vom unsichtbaren Zeichen. :-<

[MaWin (Gast)]

hidden symbol schrieb:
> Und die nächste Abhängigkeit vom unsichtbaren Zeichen. :-<

So ein Bullshit.
Mit Klammern wäre das Ergebnis exakt gleich.

[Kev G. (kev_g)]

Ich habe es jetzt geschafft dass das Fenster auftaucht bzw es 
funktioniert

Danke an alle die geholfen haben

Dennoch passiert nicht genau was passieren sollte also mein BUtton ist 
sinnlos bzw macht nichits

[Sheeva P. (sheevaplug)]

Kev G. schrieb:
> Dennoch passiert nicht genau was passieren sollte also mein BUtton ist
> sinnlos bzw macht nichits

Lieber Kev, ich habe Dir ja bei Deinen letzten Threads schon konstruktiv 
zu helfen versucht. Aber ich befürchte, Du müßtest schon ein bisschen 
mitarbeiten, wenn das funktionieren soll.

Wie dem auch sei: wenn das, was Du da oben gecodet hast, auch nur 
ansatzweise so in Deinem Buch steht, dann solltest Du es zum Feuermachen 
benutzen, vorzugsweise unter dem Gesäß seines Autors. Bitte den 
Brandbeschleuniger nicht vergessen!

Leider muß ich mich auch diesem "Jemand" [1] anschließen und sagen, daß 
ich nicht im Ansatz verstehe, was Dein Code tun soll -- und daß Dir 
leider offensichtlich verschiedene Grundlagen fehlen, die ein gutes Buch 
Dir bereits längst vermittelt haben sollte.

Deswegen neige ich zu drei Vermutungen, und weiß noch nicht, welche 
zutrifft:

1.) Dein Buch ist Mist. Das kann gut sein, seriöse Lektüre fängt 
ungefähr beim Doppelten des Preises und beim Dreifachen des Umfangs der 
Bücher des Autors an.

2.) Du hast das Buch zwar gelesen, aber nicht verstanden, was wiederum 
entweder der Qualität des Buches, oder Deinem Mangel an Vorkenntnis 
geschuldet sein kann.

3.) Du möchtest das Buch im Grunde nicht lesen und die Sprache nicht 
verstehen, sondern einfach nur irgendwas GUI-Ähnliches zusammenbasteln, 
ohne ein tieferes Verständnis für die Technik zu erlangen.

Wenn 1 und / oder 2 zutreffen, habe ich Dir bereits in einem anderen 
Deiner Threads eine bessere Lektüre empfohlen. Arbeite sie durch, spiele 
herum und schreibe erstmal ein paar Kommandozeilenprogramme, ganz 
klassisch. NICHT mit GUI-Programmen anfangen, sondern erstmal das 
Grundsätzliche lernen -- und dann bist Du mir auch weiterhin herzlich 
willkommen.

Wenn 3 zutreffen sollte, dann kann ich Dir auch nicht helfen. Und, ganz 
ehrlich und unter uns: dann will ich das auch nicht. Meine Zeit ist 
leider begrenzt, und hier gibt es genug Leute, die etwas lernen und 
verstehen wollen, und denen ich gerne mit Rat und Tat zur Seite stehe -- 
insofern wünsche ich Dir in diesem Fall viel Glück und einen schönen 
Tag.

Als Anschauungsmaterial habe ich Dir allerdings noch ein kleines 
Beispiel an diesen Beitrag angehängt, um Dir zu zeigen, wie elegant und 
lesbar sauberer Python-Tkinter-Code aussehen kann. Vergleiche das mal 
mit Deinem Code...


[1] Beitrag "Re: else: invalid syntax"

[Vancouver (Gast)]

@kev:
Diese Zwangseinrückerei treibt mich bei Python auch regelmäßig in den 
Wahnsinn. Ich habe mir anfangs angewöhnt, jede Struktur mit einem 
Kommentar abzuschließen, z.B.

            def aktion(self):
                geloescht = False
                if geloescht:
                   do_something()
                # end if
            # end aktion()

Alles zwischen "def" und "# end aktion()" muss um eine weitere Ebene 
eingerückt sein. Das gleiche beim if-Statement. Damit siehst du dann 
auch geich, wo in deinem Codeschnipsel der Fehler liegt.

Das ist zwar mehr Schreibarbeit, ist aber so hilfreich, dass ich es bis 
heute mache (nun ja, zumindest meistens...). Das hat außerdem den 
Vorteil, dass du bei langen Statements, die nicht in das Editorfenster 
passen, auf einen Blick siehst, welches Statement wo zuende ist.

[MaWin (Gast)]

Vancouver schrieb:
> Diese Zwangseinrückerei treibt mich bei Python auch regelmäßig in den
> Wahnsinn.

Mich treibt nur in der Wahnsinn, wenn Leute in Sprachen nicht richtig 
einrücken, wenn die Sprachen es nicht erzwingen.
Das ist einfach nur unlesbar. Klammern hin oder her.

[hidden symbol (Gast)]

MaWin schrieb:
> So ein Bullshit.
> Mit Klammern wäre das Ergebnis exakt gleich.
Nö, in jeder halbswegs aktuellen IDE lassen sich die zusammen gehörigen 
Klammern markern.

Sorry, aber wenn ein Block durch nicht sichtbare Zeichen geknnzeichnet 
ist un dann noch zwischen Space und Tab unterschieden wird, besch ... 
geht s kaum.

[MaWin (Gast)]

hidden symbol schrieb:
> Nö, in jeder halbswegs aktuellen IDE lassen sich die zusammen gehörigen
> Klammern markern.

Genau wie man in jedem Editor, nicht nur in "halbwegs aktuellen IDEs", 
die Zusammengehörigkeit eindeutig an der Einrückung erkennen kann.

> Sorry, aber wenn ein Block durch nicht sichtbare Zeichen geknnzeichnet

Seit wann ist eine Einrückung unsichtbar?

> ist un dann noch zwischen Space und Tab unterschieden wird, besch ...
> geht s kaum.

Tja. Dass Tab erlaubt sind, ist in der Tat nicht ganz glücklich, weil 
die Breite von der Umgebung abhängt.
Aber das ist jetzt halt so und es ist auch nicht mehr änderbar.
Du kannst ja einfach keine Tabs verwenden. Problem gelöst.

[hidden symbol (Gast)]

Formatierung dient der Formatierung, die Syntanx beschreibt die 
'Sprache'. Denke an die Konvertierungsprobleme CR und CR/LF auf 
unterschiedlichen Systemen.
Die nächste Spracherweiterung wird dann grüne und blaue Zeichen 
unterscheiden. :-(

MaWin schrieb:
> Dass Tab erlaubt sind, ist in der Tat nicht ganz glücklich, weil
> die Breite von der Umgebung abhängt.
> Aber das ist jetzt halt so und es ist auch nicht mehr änderbar.

Und damit eine Sch...lösung. Da sind wir uns ja einig. ;->

[Yalu X. (yalu) (Moderator)]

Ich kann im Code des TE keinen einzigen Tab entdecken. Daran kann es
also nicht liegen, dass seine Einrückungen nicht stimmen.

IMHO liegt es vielmehr daran, dass er die Strukturierung des Codes in
Blöcke noch nicht verstanden hat. In einer Sprache mit Klammern hätte er
somit genau die gleichen Probleme, weil er die Klammern an die falschen
Stellen setzen würde.

Threads zum Einrückungskonzept von Python und zum Thema Tabs vs Spaces
gibt es hier übrigens schon zur Genüge. Das Diese Themen müssen deswegen
nicht bei jeder unpassenden Gelegenheit wieder aufgefrischt werden.

[MaWin (Gast)]

hidden symbol schrieb:
> Formatierung dient der Formatierung, die Syntanx beschreibt die
> 'Sprache'.

Bei Python ist das halt nicht so. Ob du es magst, oder nicht.
Wenn die Formatierung bereits eindeutig die Blöcke definiert, warum 
sollte ich zusätzlich noch Klammern verlangen?

> Denke an die Konvertierungsprobleme CR und CR/LF auf
> unterschiedlichen Systemen.

Und das hat jetzt genau was mit Python zu tun?

[Ritchies Nachbar (Gast)]

MaWin schrieb:
> Du kannst ja einfach keine Tabs verwenden.

Das ist Blasphemie ;)

https://www.youtube.com/watch?v=SsoOG6ZeyUI

Wie alle richtigen Programmierer wissen, ist die beste Sprache immer 
die, die einem am besten gefaellt /s

c-hater schrieb:
> Aber ich (und jeder erfahrene Programmierer)

https://de.wikipedia.org/wiki/Kein_wahrer_Schotte

[hidden symbol (Gast)]

MaWin schrieb:
> Bei Python ist das halt nicht so. Ob du es magst, oder nicht.
> Wenn die Formatierung bereits eindeutig die Blöcke definiert, warum
> sollte ich zusätzlich noch Klammern verlangen?

Danke für die Bestätigung, dass Formatierung und Syntax bei Python 
vermischt werden. Dann warte ich mal auf die grünen und blauen Zeichen 
und welche besonderen Spracheigenschaften ihnen zugedacht werden. :-<<<

[MaWin (Gast)]

hidden symbol schrieb:
> Danke für die Bestätigung, dass Formatierung und Syntax bei Python
> vermischt werden.

Ähm, ja. Ok.
Niemand hat jemals in Frage gestellt, dass das so ist.

> Dann warte ich mal auf die grünen und blauen Zeichen
> und welche besonderen Spracheigenschaften ihnen zugedacht werden.

Wo gibt es Pläne solcherlei Dinge zu implementieren?

[Egon D. (Gast)]

hidden symbol schrieb:

> Dann warte ich mal auf die grünen und blauen
> Zeichen und welche besonderen Spracheigenschaften
> ihnen zugedacht werden. :-<<<

ColorForth ist bekannt?

[Egon D. (Gast)]

MaWin schrieb:

> Wenn die Formatierung bereits eindeutig die Blöcke
> definiert, warum sollte ich zusätzlich noch Klammern
> verlangen?

Gegenfrage: Wenn sich die Formatierung automatisch
aus der Klammersetzung ableiten lässt -- warum sollte
ich dann den Quelltext noch von Hand formatieren?

Ist das die Vorstellung von "technischem Fortschritt":
Wir zwingen den Programmierer, etwas von Hand zu
machen, was die Maschine auch automatisch erledigen
könnte?


Und zur Frage "Wozu überhaupt Blockklammern?": Die
meisten natürlichen Sprachen kennen eine Interpunktion.
Es ist also wahrnehmungspsychologisch sinnvoll, das
bei formalen Sprachen beizubehalten. Texte ohne Kommas
und Satzzeichen sind beschissen lesbar.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Egon D. schrieb:
> MaWin schrieb:
>
>> Wenn die Formatierung bereits eindeutig die Blöcke
>> definiert, warum sollte ich zusätzlich noch Klammern
>> verlangen?
>
> Gegenfrage: Wenn sich die Formatierung *automatisch*
> aus der Klammersetzung ableiten lässt -- warum sollte
> ich dann den Quelltext noch von Hand formatieren?
>
> Ist das die Vorstellung von "technischem Fortschritt":
> Wir zwingen den Programmierer, etwas von Hand zu
> machen, was die Maschine auch automatisch erledigen
> könnte?

Den C program beautifier (cb) gab es schon vor mindestens 35 Jahren:

https://www.unix.com/man-page/v7/1/cb/

"DESCRIPTION

       Cb  places  a copy of the C program from the standard input on 
the standard output with spacing and indentation that displays the 
structure of the program."

"4th Berkeley Distribution May 5, 1986"

Geben tut es das also schon viel länger als Python...

Wenn es keiner benutzt, ist das nicht die Schuld von Programmiersprachen 
mit Klammern um Blöcke oder gar irgendein Zwang.

Nur für Python kann es einen solchen Beautifier nicht geben. Ich denke 
das wäre sogar formal beweisbar, wenn man sich die Zeit nimmt.

[Jens G. (jensig)]

hidden symbol schrieb:
> MaWin schrieb:
>> Bei Python ist das halt nicht so. Ob du es magst, oder nicht.
>> Wenn die Formatierung bereits eindeutig die Blöcke definiert, warum
>> sollte ich zusätzlich noch Klammern verlangen?
>
> Danke für die Bestätigung, dass Formatierung und Syntax bei Python
> vermischt werden. Dann warte ich mal auf die grünen und blauen Zeichen
> und welche besonderen Spracheigenschaften ihnen zugedacht werden. :-<<<

Ja, aber spätestens dann mußt Du Deinen bernsteinfarbenen 
Monochrom-Monitor ausrangieren ...

[MaWin (Gast)]

Egon D. schrieb:
> Gegenfrage: Wenn sich die Formatierung automatisch
> aus der Klammersetzung ableiten lässt -- warum sollte
> ich dann den Quelltext noch von Hand formatieren?

Richtig. Ich bin voll bei dir.
Den Programmierer die Einrückung und die Klammern machen zu lassen, ist 
Unsinn.

Egon D. schrieb:
> Und zur Frage "Wozu überhaupt Blockklammern?": Die
> meisten natürlichen Sprachen kennen eine Interpunktion.
> Es ist also wahrnehmungspsychologisch sinnvoll, das
> bei formalen Sprachen beizubehalten.

Natürliche Sprachen kennen auch Einrückungen und Absätze.

[hidden symbol (Gast)]

MaWin schrieb:
> Natürliche Sprachen kennen auch Einrückungen und Absätze.

Die sind für den Inhalt aber unwichtig. Wichtig sind aber Satzzeichen, 
um Zusammengehörigkeit zu erkennen; Beziehung herzustellen und nicht 
erraten zu lassen.

[MaWin (Gast)]

hidden symbol schrieb:
> Die sind für den Inhalt aber unwichtig.

So ein Unsinn.
Sie sind wichtig um
> Zusammengehörigkeit zu erkennen

Und Gedichte hast du anscheinend auch noch nie gelesen.

[Dussel (Gast)]

Egon D. schrieb:
> Gegenfrage: Wenn sich die Formatierung automatisch
> aus der Klammersetzung ableiten lässt -- warum sollte
> ich dann den Quelltext noch von Hand formatieren?
>
> Ist das die Vorstellung von "technischem Fortschritt":
> Wir zwingen den Programmierer, etwas von Hand zu
> machen, was die Maschine auch automatisch erledigen
> könnte?
Python war ja als Lernsprache gedacht. Einrückung ist in (den meisten?) 
Hochsprachen praktisch zwingend, auch wenn es syntaktisch ohne ginge. 
Python will das erzwingen, um die Lernenden von Anfang an ans richtige 
Einrücken zu gewöhnen. Diese Idee finde ich nicht schlecht. Dass Python 
sich dann zu einer der Standardsprachen entwickelt hat, ist halt etwas 
'blöd' gelaufen, aber so ist es halt.
Rein vom Gefühl her würde ich sagen, dass die meisten 
Pythonprogrammierer Python trotz der syntaktischen Einrückung verwenden 
und nicht deswegen.

[hidden symbol (Gast)]

MaWin schrieb:
> So ein Unsinn.

Ich behaupte, einen Text auch ohne Aufteilung in Absätze lesen (und 
verstehen) zu können. Ohne Satzzeichen wird es aber schwer und 
uneindeutig; das führt zu Missverständnissen.

MaWin schrieb:
> Und Gedichte hast du anscheinend auch noch nie gelesen.

???

Der Dichter ist völlig frei von irgendwelchen Regeln. Ich hoffe, das ist 
nicht deine Vision für eine Programmiersprache. :-(

[Egon D. (Gast)]

Nikolaus S. schrieb:

> Den C program beautifier (cb) gab es schon vor
> mindestens 35 Jahren: [...]

Ja, richtig. Ich weiss.


> Geben tut es das also schon viel länger als
> Python...

Ja, eben.

Und was hat Guido van Rossum gemacht? Hat er den
(hypothetischen) "python beautifier" in den
Standard-Editor integriert? -- Nein! Er hat die
(in vielen Sprachen üblichen) Blockklammern
abgeschafft , um den Programmierer zum Einrücken
zu zwingen .

Ist das technischer Fortschritt?

[Egon D. (Gast)]

MaWin schrieb:
> Egon D. schrieb:
>> Gegenfrage: Wenn sich die Formatierung automatisch
>> aus der Klammersetzung ableiten lässt -- warum sollte
>> ich dann den Quelltext noch von Hand formatieren?
>
> Richtig. Ich bin voll bei dir.

Das kann ich nicht glauben. Das hat es ja noch nie
gegeben :)


> Den Programmierer die Einrückung und die Klammern
> machen zu lassen, ist Unsinn.

Ich bin nicht sicher, was Du damit sagen willst.

Ich meine jedenfalls, dass der fertige Quelltext
(idealerweise) sowohl Blockklammern als auch
Einrückungen enthalten sollte -- aber der
Programmierer sollte nur eins von beiden eingeben
müssen. Die Maschine sollte so schlau sein, das
andere automatisch zu ergänzen.


> Egon D. schrieb:
>> Und zur Frage "Wozu überhaupt Blockklammern?":
>> Die meisten natürlichen Sprachen kennen eine
>> Interpunktion. Es ist also wahrnehmungspsychologisch
>> sinnvoll, das bei formalen Sprachen beizubehalten.
>
> Natürliche Sprachen kennen auch Einrückungen und
> Absätze.

Richtig -- deswegen bin ich dafür, dass der fertige
Quelltext beides enthält. Das unterscheidet mich
wohl von Guido van Rossum.
Im dritten Jahrtausend sollte es allerdings genügen,
wenn der Programmierer nur eins von beiden eingeben
muss -- die Maschine sollte das andere automatisch
ergänzen können.

[Egon D. (Gast)]

hidden symbol schrieb:

> MaWin schrieb:
>> Natürliche Sprachen kennen auch Einrückungen und
>> Absätze.
>
> Die sind für den Inhalt aber unwichtig.

Das ist übertrieben; die Welt ist nicht schwarzweiss.


> Wichtig sind aber Satzzeichen, um Zusammengehörigkeit
> zu erkennen; Beziehung herzustellen und nicht erraten
> zu lassen.

Sicher -- und Absätze, Überschriften und dergleichen
sind wichtig, um sich im Text zu orientieren. Das ist
bei Quelltexten nicht anders.

[hidden symbol (Gast)]

Egon D. schrieb:
> Sicher -- und Absätze, Überschriften und dergleichen
> sind wichtig, um sich im Text zu orientieren. Das ist
> bei Quelltexten nicht anders.

Der Compiler muss sich nicht orientieren. Dem ist das völlig egal, so 
lange die Syntax stimmt.
Es geht nicht um hübsch, sondern um erforderlich.

[Vancouver (Gast)]

hidden symbol schrieb:
> Es geht nicht um hübsch, sondern um erforderlich.

Nein, es geht um Lesbarkeit und Verständlichkeit. Sourcecode, der diese 
Anforderungen nicht erfüllt, ist für die Tonne, egal wie gut er 
funktioniert. Der Code wird von Programmierern geschrieben, debuggt und 
weiterentwickelt, nicht vom Compiler. Daher steht die Notwendigkeit von 
Einrückungen völlig außer Frage, in jeder Sprache, mit oder ohne 
Klammern. Sonst kannst du wieder das Spaghetti-Basic aus den 80er 
programmieren, gerne auch mit 10 Anweisungen in jeder Zeile. Dann sieht 
dein Code aus wie ein Ziegelstein von der Seite.

Einrückungen sind aber ein Gestaltungselement, das die Lesbarkeit 
verbessert. Nicht mehr und nicht weniger. Die Art und Weise, wie Python 
den Programmierer dazu zwingt, verursacht immer wieder endlose 
Reformatierungsläufe, spätestens wenn mal einen anderer Editor verwendet 
wird. Oder man versehentlich Tabs statt Leerzeichen verwendet hat. 
Dummerweise sehen die genau gleich aus, und man kann sich den Wolf 
suchen, um die Stelle zu finden.

[MaWin (Gast)]

Vancouver schrieb:
> Nein, es geht um Lesbarkeit und Verständlichkeit. Sourcecode, der diese
> Anforderungen nicht erfüllt, ist für die Tonne, egal wie gut er
> funktioniert.

> Die Art und Weise, wie Python
> den Programmierer dazu zwingt,

Also zwingt Python den Programmierer Code zu schreiben, der nicht für 
die Tonne ist.
Ich halte das für eine gute Idee.

> verursacht immer wieder endlose
> Reformatierungsläufe, spätestens wenn mal einen anderer Editor verwendet
> wird. Oder man versehentlich Tabs statt Leerzeichen verwendet hat.
> Dummerweise sehen die genau gleich aus, und man kann sich den Wolf
> suchen, um die Stelle zu finden.

Ach komm.
Tabs ersetzen ist in vielen Editoren nur ein einziger Knopfdruck und in 
allen anderen Editoren automatisiert durch Suchen-ersetzen.

Ich programmiere seit Ewigkeiten Python und habe noch nie irgendein 
Problem mit Tabs vs. Spaces gehabt. Das ist einfach nur ein 
daherfantasiertes Problem.

[Yalu X. (yalu) (Moderator)]

Python hat einen starken Fokus auf RAD und gute Lesbarkeit. Deswegen
wurde beim Entwurf der Sprache versucht, Redundanz möglichst zu
minimieren. Das äußert sich vor allem in der dynamischen Typisierung,
die ohne Variablendeklarationen auskommt, aber eben auch im Weglassen
von Blockklammern. Beides hat natürlich auch seine Nachteile, weswegen
oft Kritik daran laut wird. Für diejenigen, die statische Typisierung
und Blockklammern ein Muss sind, gibt es aber ja zum Glück genügend
Alternativen, bspw. C und C++, die beide auch noch weitere Vorteile
haben.

Ich persönlich empfinde Python-Code (zumindest wenn er von jemandem
geschrieben wurde, der die Python-Philosophie halbwegs verstanden hat)
als viel leichter lesbar als bspw. C oder C++. Das hängt ganz einfach
damit zusammen, dass in Python selbst komplexere Algorithmen sehr
kompakt und übersichtlich implementiert werden können, so dass sie oft
als Ganzes auf dem Bildschirm dargestellt werden können, während man in
C/C++ oft mehrmals hinauf- und hinabscrollen muss, bis man sich den
nötigen Überblick verschafft hat.

Die Knappheit von Python verbunden mit dessen Ausdrucksstärke führt aber
auch dazu, dass ich Programmcode in Python sehr viel schneller schreiben
kann als in C/C++.

Zu dieser Kompaktheit tragen – wenn auch nur zu einem Teil – auch die
fehlenden Blockklammern bei, die in C/C++ die je nach Einrückungsstil 1
oder sogar 2 zusätzliche Zeilen pro Klammerpaar benötigen. Schon das
alleine erhöht die Anzahl der Codezeilen bei der Verwendung vieler
Kontrollstrukturen schnell mal um 50%, was die Wahrscheinlichkeit, einen
komplexeren Codeabschnitt ohne Scrollen auf einen Blick erfassen zu
können, stark verringert.

Die von einigen immer wieder hochstilisierte Fehlerträchtigkeit der
Python-Einrückungen ist zwar existent, IMHO aber weitgehend harmlos.
Genauso oft (und nur sehr selten), wie ich Python falsch einrücke,
vergesse ich in C/C++ die Klammern oder setze sie an die falsche Stelle.
Sowohl in C/C++ als auch in Python wird man in vielen Fällen auf den
Fehler hingewiesen (wenn dadurch eine Syntaxregel gebrochen wird), in
den Fällen, wo dies nicht geschieht, finde den Fehler auch schnell
selber.

Mal Hand aufs Herz: Was war die längste Zeitdauer, in der ihr in Python
nach einem Fehler gesucht habt, der sich hinterher aus Einrückungsfehler
herausgestellt hat, und wie oft ist das euch schon passiert?


Für diejenigen, die Python nur wegen des Einrückkonzepts nicht mögen,
gibt es Lösungen:

  https://github.com/mathialo/bython
  https://python-with-braces.appspot.com/
  https://pypi.org/project/brackets/
  https://hackaday.com/2014/02/10/python-with-braces/

Es gibt noch einen anderen Ansatz (den ich im Netz leider gerade nicht
finde), bei dem die Klammern als #{ und #} (bzw. #begin und #end) in
Kommentare gestellt werden, so dass an der Syntax der Sprache selber
keinerlei Änderungen notwendig sind, d.h. der Code wie gewohnt ohne
Präprozessor o.ä. direkt ausgeführt werden kann.

Diese Kommentare können bspw. von einem Re-Indent-Tool, Editoren und
dergleichen genutzt werden. Es gibt dafür auch Tools zum automatischen
Einfügen dieser Klammern in existierenden (und bereits korrekt
eingerückten) Python-Code und zum automatischen Entfernen der Klammern.
Dies bietet bspw. die Möglichkeit, den Code beim Laden in den Editor zu
klammern und beim Abspeichern wieder zu entklammern, so dass in einer
Entwicklergruppe, in der nicht alle Mitglieder diese Klammern wollen,
diese dadurch nicht unnötig gestört werden.


Allzu populär scheinen die genannten Python-Erweiterungen aber nicht zu
sein, weswegen die Entwicklung einiger davon auch wieder eingestellt
wurde.

Diese schlechte Akzeptanz hat IMHO die folgenden Gründe:

- Die meisten Python-Nutzer finden das bestehende Einrückkonzept gut
  oder stören sich zumindest nicht daran.

- Von denjenigen, die das Einrückkonzept laut kritisieren, haben
  vermutlich viele eine generelle Abneigung gegen Python (bspw. wegen
  der dynamischen Typisierung), weswegen sie Python auch dann nicht
  nutzen würden, wenn es Blockklammern gäbe.

- Der Rest (also die Gruppe derjenigen, die Python ausschließlich wegen
  des Einrückkonzepts ablehnen) ist vermutlich so klein, dass die
  Entwicklung von Python-Erweiterungen wie den oben genannten kaum auf
  fruchtbaren Boden fällt.


Um am Ende auch selber mal herbe Kritik an der Python-Syntax
loszuwerden:

Mich stören ganz gewaltig

- Die hässlichen Doppelpunkte am Ende jeder Zeile mit if, while, for,
  def usw.: Diese Doppelpunkte widersprechen ganz klar dem Prinzip der
  reduzierten Redundanz und könnten IMHO ohne irgendwelche Konflikte
  beim Parsen ersatzlos aus der Syntaxdefinition gestrichen werden.

- Die Länge des Schlüsselworts "lambda": Lambda-Ausdrücke dienen ja u.a.
  dazu, kompakte Funktionsdefinitionen innerhalb anderer Ausdrücke
  (bspw. als Argumente in Funktionsaufrufen) zu definieren. In vielen
  Fällen ist aber das Schlüsselwort zusammen mit dem nachfolgenden,
  zwingend erforderlichen Leerzeichen länger als die eigentliche
  Funktionsdefinition  (bspw. in lambda x:x+1). IHMO sollte man "lambda"
  einfach durch einen Backslash ersetzen. Das vorige Beispiel würde sich
  damit auf \x:x+1 reduzieren. Auch das ließe sich ohne Parserkonflikte
  ändern, da der Backslash ansonsten nur als Escape-Zeichen in
  Stringliteralen und als Fortsetzungszeichen am Zeilenende verwendet
  wird.

Da ich aber sonst mit Python mehr als zufrieden bin, mache ich deswegen
keinen großen Aufstand :)

[Dussel (Gast)]

Yalu X. schrieb:
> Mich stören ganz gewaltig
> [...]
> Da ich aber sonst mit Python mehr als zufrieden bin, mache ich deswegen
> keinen großen Aufstand :)
Ich könnte mir vorstellen, dass das bei vielen auch für die erzwungene 
Einrückung gilt. Nur weil man sich nicht beschwert, heißt das nicht, 
dass man sich nicht daran stört.
Ich denke, dazu gibt es keine Statistik, aber interessieren würde es 
mich doch.

PS: Zeilenumbrüche in Zitaten scheinen nicht richtig zu funktionieren. 
Die drei Punkte sollten in einer eigenen Zeile stehen.

[Dussel (Gast)]

Dussel schrieb:
> PS: Zeilenumbrüche in Zitaten scheinen nicht richtig zu funktionieren.
> Die drei Punkte sollten in einer eigenen Zeile stehen.
PS: Die Vorschau zeigt Zitate nicht so an, wie sie am Ende aussehen. In 
der Vorschau war das ganze Zitat zusammengezogen.

[Egon D. (Gast)]

hidden symbol schrieb:

> Egon D. schrieb:
>> Sicher -- und Absätze, Überschriften und dergleichen
>> sind wichtig, um sich im Text zu orientieren. Das ist
>> bei Quelltexten nicht anders.
>
> Der Compiler muss sich nicht orientieren.

???

Der Compiler nicht -- aber der Mensch . Quelltexte
werden öfter gelesen (auch vom Menschen) als
geschrieben.


> Es geht nicht um hübsch, sondern um erforderlich.

Für den Menschen ist anderes erforderlich als für
den Compiler. Für den Menschen ist "hübsch" sehr
wohl erforerlich.

[Egon D. (Gast)]

Yalu X. schrieb:

> Python hat einen starken Fokus auf RAD und gute
> Lesbarkeit. Deswegen wurde beim Entwurf der Sprache
> versucht, Redundanz möglichst zu minimieren.

Das "deswegen" ist meiner Meinung nach unzutreffend,
wenigstens was die Lesbarkeit angeht.

Die meisten natürlichen Sprachen enthalten ein
erhebliches Maß an Redundanz; nur deswegen
funktionieren sie im Alltag einigermaßen.


> Ich persönlich empfinde Python-Code (zumindest
> wenn er von jemandem geschrieben wurde, der die
> Python-Philosophie halbwegs verstanden hat) als
> viel leichter lesbar als bspw. C oder C++. Das
> hängt ganz einfach damit zusammen, dass in Python
> selbst komplexere Algorithmen sehr kompakt und
> übersichtlich implementiert werden können,

Ich denke, dass trifft auf zahlreiche halbwegs
aktuelle Scriptsprachen zu. Für Tcl würde ich es
zumindest unterschreiben.


> Zu dieser Kompaktheit tragen – wenn auch nur zu einem
> Teil – auch die fehlenden Blockklammern bei, die in
> C/C++ die je nach Einrückungsstil 1 oder sogar 2
> zusätzliche Zeilen pro Klammerpaar benötigen. Schon
> das alleine erhöht die Anzahl der Codezeilen [...]

Bei mir entsteht (Tcl-typisch) immer nur eine zusätzliche
Zeile (für die schließende Blockklammer), aber die stört
mich nicht.
In fast jeden (längeren) Quelltext füge ich sogar
zusätzliche Leerzeilen ein, um komplexere Operationen
auch optisch voneinander abzusetzen und mir die
Orientierung zu erleichtern. Fällt mir erst jetzt auf,
wo ich so darüber schreibe.


> Die von einigen immer wieder hochstilisierte
> Fehlerträchtigkeit der Python-Einrückungen [...]

Da ich nicht in Python programmiere, kann ich zu Fehlern
beim SCHREIBEN des Codes nix sagen.

Mir fällt aber auf, dass meine Ladehemmung beim LESEN
von Python-Code viel höher ist als z.B. beim Lesen von
C-Code, obwohl ich auch in C Anfänger bin.


> - Von denjenigen, die das Einrückkonzept laut
>   kritisieren, haben vermutlich viele eine generelle
>   Abneigung gegen Python (bspw. wegen der dynamischen
>   Typisierung),

Tcl ist auch dynamisch typisiert; insofern ist das für
mich nicht relevant.


> - Die hässlichen Doppelpunkte am Ende jeder Zeile mit
>   if, while, for, def usw.: Diese Doppelpunkte
>   widersprechen ganz klar dem Prinzip der reduzierten
>   Redundanz

Die sind m.E. der halbherzige Ersatz für die Blockklammern.
Doppelpunkt ist auf einer Tastatur mit deutscher Belegung
deutlich besser erreichbar als die geschweifte Klammer...

[Vancouver (Gast)]

MaWin schrieb:
> Ich halte das für eine gute Idee.

Ich halte es für eine bessere Idee, alle nicht-funktionalen Aspekte des 
Sourcecodes der Disziplin des Programmierers zu überlassen. Dazu gibt es 
Styleguides, die jede Menge Empfehlungen enthalten, auch zum Thema 
Indents. Wer guten Code schreibt, muss sich ohnehin an einen Styleguide 
halten. Da gehört nämlich noch mehr viel dazu als nur Einrückungen.

> Tabs ersetzen ist in vielen Editoren nur ein einziger Knopfdruck und in
> allen anderen Editoren automatisiert durch Suchen-ersetzen.

Und in beiden Fällen zusätzliche Arbeit, die durch entsprechende Tags 
vermieden werden könnte.

Yalu X. schrieb:
> Die Knappheit von Python verbunden mit dessen Ausdrucksstärke führt aber
> auch dazu, dass ich Programmcode in Python sehr viel schneller schreiben
> kann als in C/C++.

Das liegt aber in erster Linie daran, dass in Python schon jede Menge 
Strukturen vordefiniert sind, die man in anderen Sprachen erst selber 
schreiben oder durch eine Library einbinden muss. Stichwort 
Dictionaries, Listen, Tupel...

Yalu X. schrieb:
> Mal Hand aufs Herz: Was war die längste Zeitdauer, in der ihr in Python
> nach einem Fehler gesucht habt, der sich hinterher aus Einrückungsfehler
> herausgestellt hat, und wie oft ist das euch schon passiert?

Ich hab nicht mit der Stoppuhr da gesessen, aber passiert ist es oft, 
auch heute nach gut 15 Jahren Python passiert es noch. Besonders 
ärgerlich wird es, wenn eine falsche Einrückung nicht zu einer 
Fehlermeldung führt sondern nur zu einem falschen Verhalten. Man kann 
nur den Kopf schütteln, wenn eine Zeile Code zu völlig anderen 
Ergebnissen führt, wenn man sie vier Leerzeichen weiter einrückt.

Ich verbringe jedenfalls ganz sicher mehr Zeit in Python mit dem 
Aufdröseln von Indents als mit der Korrektur von Klammern oder Tags in 
anderen Sprachen.

Beispiel: Oft hat man am Ende einer C-Funktion eine ganze Kaskade von 
schließenden Klammern. In Python steht da einfach - nichts. Wenn man nun 
in dieses Nichts an der richtigen Stelle noch eine Zeile einfügen will, 
muss man erstmal hochscrollen und schauen, wieviele Tabs und/oder 
Leerzeichen die richtige Strukturebene hat. Das ist einfach nur 
ärgerlich, zeitraubend und fehleranfällig. Klar gibt es Editoren, die 
die Indent-Ebenen als Linien darstellen, das machts einfacher. Aber die 
eigentliche Struktur muss dann eben erst durch Hilfsmittel sichtbar 
gemacht werden. Das ist doch nicht der Sinn der Sache. Klammern sind da 
unmissverständlich und eindeutig, in jedem Editor (sogar im vi).

[Yalu X. (yalu) (Moderator)]

Vancouver schrieb:
> Beispiel: Oft hat man am Ende einer C-Funktion eine ganze Kaskade von
> schließenden Klammern.

Ja, schrecklich.

> In Python steht da einfach - nichts.

Vollkommen ausreichend.

> Wenn man nun in dieses Nichts an der richtigen Stelle noch eine Zeile
> einfügen will, muss man erstmal hochscrollen und schauen, wieviele Tabs
> und/oder Leerzeichen die richtige Strukturebene hat.

Hochscrollen muss man doch sowieso, auch in C, um zu sehen, was in
welcher Ebene genau getan wird. Wenn ich nur das

            x = 1;
          }
        }
      }
    }
  }

sehe, weiß ich doch nicht, wo ich die neue Zeile einfügen möchte, es sei
denn, ich habe den darüberliegenden Code im Kopf. Ist das tatsächlich
der Fall, dann weiß ich, dass ich – ausgehend von der letzten Codezeile
– bspw. 2 Einrückungsebenen nach links gehen muss. In C drücke ich dazu
zweimal auf Cursor-Down, in Python stattdessen zweimal auf Backspace
(Vim ist so eingestellt, dass Backspace auch Autoindents löscht), um an
die gewünschte Stelle zu gelangen. Wo ist da der große Unterschied?

[Vancouver (Gast)]

Yalu X. schrieb:
> Ja, schrecklich.
Schrecklich eineindeutig.

Yalu X. schrieb:
> Vollkommen ausreichend.
Wenn man daran Spaß hat, sich den Rest zu denken.

Yalu X. schrieb:
> Wo ist da der große Unterschied?

Hier:

                     bla()
                     bla()
                     bla()
            blub()

Na, wieviele Einrückunsebenen liegen zwischen dem letzten bla() und dem 
blub()? Eine? Zwei? Sieben?
Und jetzt das:

                     bla();
                     bla();
                     bla();
                   };
                 };
               };
             };
             blub();
           };
         };

Da schau an, es waren vier. Wer hätte das gedacht. Und es gibt sogar 
noch zwei danach.

[G. P. (gpnt)]

Vancouver schrieb:

> Na, wieviele Einrückunsebenen liegen zwischen dem letzten bla() und dem
> blub()? Eine? Zwei? Sieben?
> Und jetzt das:                     bla();
>                      bla();
>                      bla();
>                    };
>                  };
>                };
>              };
>              blub();
>            };
>          };
>
> Da schau an, es waren vier. Wer hätte das gedacht. Und es gibt sogar
> noch zwei danach.

Die Frage ist doch ob mich die Zahl interessiert auf welcher Ebene ich 
nun bin und wie viele Ebenen zwischen zwei Zeilen liegen oder ob mich 
der Kontext interessiert zu welchem eine bestimmte Zeile gehört.
Ich kann mit deinem ersten Python-Codeblock genauso wenig anfangen wie 
mit deinem C-Codeblock.
Mich interessiert nicht ob zwischen bla() und blub() vier ebenen liegen, 
sondern was über blub() in der selben Ebene steht. Und da orientiere ich 
mich an der Einrückung, egal ob in C oder Python.
Unf falls über blub() zu viel Code steht, so dass ich es nicht mehr 
erkennen kann, klicke ich auf das (-) im Editor um bestimmte Blöcke 
auszublenden.

[Yalu X. (yalu) (Moderator)]

Bei bis zu 4 oder 5 Ausrückungen erkennt man deren Anzahl noch ganz gut,
wenn man sich auf eine fixe Einrückungbreite (bspw. 2 oder 4 Spaces)
festgelegt hat und sich ein wenig daran gewöhnt hat. Bei einer
Einrückungstiefe von mehr als 5 Ebenen innerhalb einer Funktion sollte
man evtl. über seinen Programmierstil nachdenken.

In deinem ersten Beispiel hast du übrigens 9 Zeichen ausgerückt. Geht
man von einer Einrückungbreite von 2 Spaces (wie in deinem zweiten
Beispiel) aus, und ist der restliche Code korrekt eingerückt, würde
Python in der Zeile mit dem blub() meckern:

IndentationError: unindent does not match any outer indentation level

Man darf in tief verschachteltem Code die einzelnen Blöcke aber auch
gerne mit einem Kommentar abschließen. Dann erkennt man nicht nur,
dass ein Block abgeschlossen wird, sondern auch gleich welcher :

                    bla()
                    bla()
                    bla()
                  # end if
                # end for z
              # end for y
            # end for x
            blub()

Solche Kommentare sieht man auch mitunter in C-Code, weil in einer
Kolonne mehrerer schließender Klammern die einzelnen Klammern für sich
gesehen wenig aussagekräftig sind.

[Vancouver (Gast)]

Yalu X. schrieb:
> In deinem ersten Beispiel hast du übrigens 9 Zeichen ausgerückt

Ja, das war ja auch nur ein plakatives Beispiel, um zu zeigen, dass man 
da nichts sehen kann. Ohne mit dem Cursor zu zählen, weißt du nicht, 
wieviele Ebenen dazwichen liegen.

Dein Hinweis mit den Kommentaren ist genau das, was ich auch verwende in 
Python,  außer bei sehr kurzen Codestücken. Faktisch fügt man damit eben 
die Klammern als Kommentar ein.

G. P. schrieb:
> Die Frage ist doch ob mich die Zahl interessiert auf welcher Ebene ich
> nun bin

Bei n-fach verschachtelten Schleifen oder if-Kaskaden weißt du nach n 
Klammern, dass du wieder draußen bist. Bei Python weiß du es nicht ohne 
Hilfmittel.

[Yalu X. (yalu) (Moderator)]

Vancouver schrieb:
> G. P. schrieb:
>> Die Frage ist doch ob mich die Zahl interessiert auf welcher Ebene ich
>> nun bin
>
> Bei n-fach verschachtelten Schleifen oder if-Kaskaden weißt du nach n
> Klammern, dass du wieder draußen bist. Bei Python weiß du es nicht ohne
> Hilfmittel.

Anstatt die Verschachtelungen mitzuzählen, finde ich es praktischer,
einfach kurz zum Blockanfang (also zur nächstgelegenen, weniger weit
eingerückten Zeile nach oben) und wieder zurück zu springen. Dann sieht
man auch gleich, um welche Art von Block es sich handelt (if, for,
Funktionsdefinition etc.) und in welchem Kontext er angesiedelt ist.

[hidden symbol (Gast)]

Yalu X. schrieb:
> Man darf in tief verschachteltem Code die einzelnen Blöcke aber auch
> gerne mit einem Kommentar abschließen. Dann erkennt man nicht nur,
> dass ein Block abgeschlossen wird, sondern auch gleich welcher :
>
>                     bla()
>                     bla()
>                     bla()
>                   # end if
>                 # end for z
>               # end for y
>             # end for x
>             blub()

Das ist jetzt nicht dein Ernst, oder? :-<

Da philosophierst du hier über eine Kette von Beiträgen, wie toll es ist 
nur einzurücken und keine sichtbaren Zeichen zu haben. Und jeztz 
das(?!)
Du ersetzt eine schließende Klammer durch einen Kommentar, wofür du 
extra noch dein neues Symbol definierst: end.

Mehr fällt mir jetzt dazu auch nicht mehr ein, als end .

[Horst G. (horst_g532)]

MaWin schrieb:
> Vancouver schrieb:
>
>> Nein, es geht um Lesbarkeit und Verständlichkeit. Sourcecode, der diese
>> Anforderungen nicht erfüllt, ist für die Tonne, egal wie gut er
>> funktioniert.
>
>> Die Art und Weise, wie Python
>> den Programmierer dazu zwingt,
>
> Also zwingt Python den Programmierer Code zu schreiben, der nicht für
> die Tonne ist.

Grundkurs "Logik für Anfänger", Lektion 1, MaWin-Edition: Nur weil 
Sourcecode, der nicht lesbar und/oder verständlich geschrieben ist, für 
die Tonne ist, bedeutet das nicht, dass automatisch die Negation dieser 
Behauptung falsch sein muss, d. h. lesbarer und/oder verständlich 
geschriebener Code ist nicht automatisch nicht für die Tonne.
Oder plakativer: Auch mit Python lässt sich ganz hervorragend Code "für 
die Tonne" schreiben.

[Yalu X. (yalu) (Moderator)]

hidden symbol schrieb:
> Du ersetzt eine schließende Klammer durch einen Kommentar

Ich schrieb, dass man das so machen darf, nicht muss. Ich selber 
mache es nicht so (falls dieser Eindruck entstanden sein sollte). Es ist 
vielmehr als Hilfe für diejenigen gedacht, die sonst mit den 
Einrückungen nicht zurecht kommen.

Dass einige C/C++-Programmierer solche Kommentare sogar zusätzlich zu 
den sowieso erforderlichen Klammern verwenden, zeigt aber, dass sie 
(zumindest für diese Leute) durchaus einen gewissen Nutzen haben.

> wofür du extra noch dein neues Symbol definierst: end.

Du darfst das "end" auch gerne durch "{" ersetzen oder einfach 
weglassen. Du darfst die Kommentare auch komplett weglassen. Du darfst 
auch weiterhin über die Einrückungen in Python schelten wie ein 
Rohrspatz. Ich weiß nur nicht, was das bringen soll, außer dass du dich 
hinterher vielleicht etwas besser fühlst ;-)

[Sheeva P. (sheevaplug)]

Vancouver schrieb:
> @kev:
> Diese Zwangseinrückerei treibt mich bei Python auch regelmäßig in den
> Wahnsinn. Ich habe mir anfangs angewöhnt, jede Struktur mit einem
> Kommentar abzuschließen, z.B.
>
>

>             def aktion(self):
>                 geloescht = False
>                 if geloescht:
>                    do_something()
>                 # end if
>             # end aktion()
>

Wenn man ein kluges Kerlchen wäre, könnte man natürlich anstelle eines 
Kommentars eines der Schlüsselworte "pass" oder "return" benutzen. Aber 
vermutlich muß man sich dazu mit der Sprache auskennen und einen 
anständigen Editor benutzen.

[Sheeva P. (sheevaplug)]

hidden symbol schrieb:
> MaWin schrieb:
>> Bei Python ist das halt nicht so. Ob du es magst, oder nicht.
>> Wenn die Formatierung bereits eindeutig die Blöcke definiert, warum
>> sollte ich zusätzlich noch Klammern verlangen?
>
> Danke für die Bestätigung, dass Formatierung und Syntax bei Python
> vermischt werden.

Nein, kleiner Troll. Guido van Rossum hat festgestellt, daß gute 
Entwickler ihren Code ohnehin IMMER sauber formatieren -- und sich dann 
überlegt: wenn die guten (also anscheinend nicht Du, wenn es Dich so 
stört) das ohnehin tun, kann so etwas auch die Syntax wesentlich 
einfacher und deutlich lesbarer machen.

[Sheeva P. (sheevaplug)]

Dussel schrieb:
> Python war ja als Lernsprache gedacht.

Nein.

[Sheeva P. (sheevaplug)]

hidden symbol schrieb:
> Es geht nicht um hübsch, sondern um erforderlich.

Richtig -- und in Python ist es so, daß es ganz wunderbar ohne 
Blockklammern auskommt. Sind Blockklammern also erforderlich? Nein, 
offensichtlich nicht, es funktioniert ganz wunderbar ohne.

Vielen Dank, daß wir das abschließend klären konnten.

[Sheeva P. (sheevaplug)]

Dussel schrieb:
> Ich könnte mir vorstellen, dass das bei vielen auch für die erzwungene
> Einrückung gilt. Nur weil man sich nicht beschwert, heißt das nicht,
> dass man sich nicht daran stört.
> Ich denke, dazu gibt es keine Statistik, aber interessieren würde es
> mich doch.

Naja... Python ist seit einiger Zeit die beliebteste 
General-Purpose-Skriptsprache und führt seit Jahren die "Most Wanted 
Programming Language"-Kategorie in den Umfragen von Stackoverflow an.

[Sheeva P. (sheevaplug)]

Vancouver schrieb:
> Ich halte es für eine bessere Idee, alle nicht-funktionalen Aspekte des
> Sourcecodes der Disziplin des Programmierers zu überlassen. Dazu gibt es
> Styleguides, die jede Menge Empfehlungen enthalten,

Weißt Du, ich komme von Basic über Assembler und C zu C++, habe als 
Skriptsprache lange Perl benutzt und bin dann zu Python gewechselt. 
Bisschen anderes Zeugs habe ich auch noch mitgenommen, egal... weißt Du, 
was der Unterschied ist?

In jeder anderen mir bekannten Sprache muß ich mir Mühe geben, lesbaren 
Code zu schreiben. In Python muß ich mir Mühe geben, unlesbaren Code zu 
schreiben.

[Teo D. (teoderix)]

Mal völlig davon abgesehen, das ich ein Faulerhund bin.... Lesbarkeit 
hin o. her, mir gehts da erstmal ums Schreiben! Durch das automatisch 
Einrücken fällt doch meist sofort auf, das da was nicht stimmen kann, 
oder es meckert der Compiler. Also ohne, wäre MIR das viel zu 
fehlerträchtig.

[Vancouver (Gast)]

Sheeva P. schrieb:
> Weißt Du, ich komme von Basic über Assembler und C zu C++, habe als
> Skriptsprache lange Perl benutzt und bin dann zu Python gewechselt.

Bis auf Perl war es bei mir genauso. Nach Basic kam noch eine längere 
Pascal-Phase. Oh Mann, das waren noch Zeiten...

Sheeva P. schrieb:
> In Python muß ich mir Mühe geben, unlesbaren Code zu
> schreiben.

Ja, weil der unlesbare Code in Python per Definition erst gar nicht 
funktioniert. Das erinnert mich an einen meiner Mathematiklehrer (ca. 9. 
Klasse), der uns selbst bei vollkommen richtig gelöster Aufgabe Punkte 
abgezogen hat, wenn die Gleichheitszeichen nicht genau untereinander 
gestanden haben. Da haben die Noten nicht mehr unbedingt die 
Mathematikkenntnisse widergespiegelt.

Wie gesagt, ich sehe die Lesbarkeit des Codes in der Verantwortung des 
Entwicklers, nicht des Tools. Der letzte Schritt bei der Entwicklung 
einer Funktion ist immer das "Beautifying", also das Aufhübschen des 
Codes mit Indents, Kommentaren, Docstrings etc., damit andere und man 
selbst den Code auch nach Monaten noch versteht. Die meisten Entwickler 
erfüllen diese Anforderung gerne, aber sie lassen sich solche Dinge 
andererseits auch nicht gerne von einem Tool vorschreiben.

[MaWin (Gast)]

Vancouver schrieb:
> Na, wieviele Einrückunsebenen liegen zwischen dem letzten bla() und dem
> blub()? Eine? Zwei? Sieben?

Es ist eine völlig sinnlose Information zu wissen, wie viele Ebenen 
zwischen Blockenden liegen.
Man muss sowieso zu den Blockanfängen scrollen, um die Blockenden 
interpretieren zu können.

Und wenn die so weit auseinander sind, dass du dir die Finger 
wundscrollst, dann ist deine Programmstruktur Mist. Unabhängig von der 
Sprache.

[Yalu X. (yalu) (Moderator)]

MaWin schrieb:
> Es ist eine völlig sinnlose Information zu wissen, wie viele Ebenen
> zwischen Blockenden liegen.
> Man muss sowieso zu den Blockanfängen scrollen, um die Blockenden
> interpretieren zu können.
>
> Und wenn die so weit auseinander sind, dass du dir die Finger
> wundscrollst, dann ist deine Programmstruktur Mist.

Erstens das, aber auch wenn ein Block ausnahmsweise einmal etwas länger
wird, muss man sich deswegen noch lange nicht die Finger wundscrollen.
Mit einem entsprechenden Editor/IDE-Plugin kann auch direkt zur
gewünschten Zeile und wieder zurückspringen. Für Vim gibt es dafür u.a.
IndentWise:

  https://github.com/jeetsukumaran/vim-indentwise

Damit kann man mit einfachen Tastenkombinationen vorwärts oder rückwärts
zur nächstgelegenen Zeile mit kleinerer, gleicher, größerer oder absolut
vorgegebener Einrückungsebene springen. Mit Ctrl-O (Vim-Standardbefehl)
springt man genauso schnell wieder zur ursprünglichen Cursorposition
zurück. Mal schnell nachschauen, in welchem Block, in welcher Funktion
oder in welcher Klasse man sich gerade befindet, ist damit – unabhängig
von der Sprungweite – eine Sache von 1 bis 2 Sekunden.

Ich habe IndentWise ursprünglich mit dem Fokus auf Python installiert,
nutze es seither aber auch für Programmiersprachen mit Blockklammern,
weil es trotz seiner Einfachheit äußerst vielseitig ist.

Ich bin mir sicher, dass Emacs, Eclipse usw. ähnliche Möglichkeiten
bieten, man muss nur bereit sein, sie zu nutzen.

[Sheeva P. (sheevaplug)]

Vancouver schrieb:
> Sheeva P. schrieb:
>> In Python muß ich mir Mühe geben, unlesbaren Code zu
>> schreiben.
>
> Ja, weil der unlesbare Code in Python per Definition erst gar nicht
> funktioniert.

Ja. Super, oder?

> Wie gesagt, ich sehe die Lesbarkeit des Codes in der Verantwortung des
> Entwicklers, nicht des Tools. Der letzte Schritt bei der Entwicklung
> einer Funktion ist immer das "Beautifying", also das Aufhübschen des
> Codes mit Indents, Kommentaren, Docstrings etc., damit andere und man
> selbst den Code auch nach Monaten noch versteht.

Also Du beschwerst Dich darüber, daß Python Dir einen langweiligen, 
überflüssigen, fehlerträchtigen und blöden Schritt erspart? Auf so eine 
Idee würde ich nichtmal kommen, wenn mich jemand dafür bezahlt. ;-)

> Die meisten Entwickler
> erfüllen diese Anforderung gerne, aber sie lassen sich solche Dinge
> andererseits auch nicht gerne von einem Tool vorschreiben.

Aber daß das "Tool" ihnen krudes Klammer-Gehacke -- das auf deutschen 
und anderen Tastaturen obendrein regelmäßig zu lustigen Verrenkungen 
führt -- vorschreibt, das nehmen sie klaglos hin? Das ist doch nicht 
Dein Ernst...

[Vancouver (Gast)]

Sheeva P. schrieb:
> Aber daß das "Tool" ihnen krudes Klammer-Gehacke -- das auf deutschen
> und anderen Tastaturen obendrein regelmäßig zu lustigen Verrenkungen
> führt -- vorschreibt, das nehmen sie klaglos hin?

Genau. Deswegen verwendest du in Python sicher auch keine Dictionaries 
oder Listen, und Verschachtelungen davon schon gar nicht. Alles krudes 
Klammer-Gehacke. Echt blöd jetzt, dass die nicht mit Indents 
strukturiert sind.

Sheeva P. schrieb:
> Das ist doch nicht
> Dein Ernst...

Nee, war alles nur Spaß. Lassen wir's gut sein.

[Mark B. (markbrandis)]

Sheeva P. schrieb:
> In jeder anderen mir bekannten Sprache muß ich mir Mühe geben, lesbaren
> Code zu schreiben. In Python muß ich mir Mühe geben, unlesbaren Code zu
> schreiben.

Vergibt Python etwa automatisch sinnvolle Namen für Funktionen und für 
Variablen? Muss das nicht mehr der Programmierer tun?

Wow, das ist ja eine tolle Sprache. :-D

[Sheeva P. (sheevaplug)]

Mark B. schrieb:
> Sheeva P. schrieb:
>> In jeder anderen mir bekannten Sprache muß ich mir Mühe geben, lesbaren
>> Code zu schreiben. In Python muß ich mir Mühe geben, unlesbaren Code zu
>> schreiben.
>
> Vergibt Python etwa automatisch sinnvolle Namen für Funktionen und für
> Variablen? Muss das nicht mehr der Programmierer tun?

Das kommt darauf an, wie ich es programmiere. Schließlich ist Python 
eine enorm dynamische Sprache, bei der ich ganz nach Belieben Klassen, 
Methoden, und auch  Funktionen erzeugen kann, schau mal:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from functools import partial
from num2words import num2words

class Yeah:
    '''a class that dynamically creates its methods and names'''
    def __init__(self, lang='de'):
        self.value = None
        def sv(self, v): self.value = v
        for i in range(0, 20, 4):
            fname = 'set'+ num2words(i, lang=lang).capitalize()
            setattr(self, fname, partial(sv, self, i))
        delattr(self, 'setNull')

    def __repr__(self):
        return '<{} value={}>'.format(self.__class__.__name__, self.value)

if __name__ == '__main__':
    y = Yeah(); print(y)
    y.setVier(); print(y)
    y.setZwölf(); print(y)
    print([i for i in dir(y) if not i.startswith('_')])

Ausgabe:

<Yeah value=None>
<Yeah value=4>
<Yeah value=12>
['setAcht', 'setSechzehn', 'setVier', 'setZwölf', 'value']

Ach ja: das Programm benötigt natürlich offensichtlich das Paket 
"num2words", welches nicht Teil der Standarddustribution ist, mit "pip 
install num2words" jedoch ganz leicht nachinstalliert werden kann -- 
vielleicht besser in einer virtuellen Umgebung (virtualenv oder venv).

> Wow, das ist ja eine tolle Sprache. :-D

Ja, nicht wahr? Wobei, am Rande bemerkt und um der nächsten 
"hochintelligenten Frage" vorzubeugen, das oben Gezeigte natürlich nur 
ein vereinfachtes Beispiel ist. In der realen Welt kann man mit so etwas 
unglaublich coole Sachen machen, beispielsweise nutze ich solche Tricks 
gerne, um dynamische Klassen aus meinen Konfigurationsdateien zu 
erzeugen, oder gerne auch Webformular-Klassen mit dem WTForms-Modul und 
Daten aus einer Konfigurationsdatei oder einer Datenbank. Oh, ach ja: in 
einer realen Welt würde ich natürlich Getter (und eventuell Setter) mit 
einem Descriptor erzeugen und an die Klasse statt der Instanz binden. 
;-D

Nein, im Ernst: wenn Du Fragen zu Python hast, bist Du mir natürlich 
jederzeit sehr herzlich willkommen. Bis dahin empfehle ich immer wieder 
gerne den Artikel von Eric S. Raymond, dessen Erfahrungen meinen 
ausgesprochen ähnlich sind, von unserer anfänglichen Ablehnung wegen 
dieser Sache mit dem Whitespace, über das Beeindrucktsein, bis hin zum 
Verlieben: [1]. Viel Vergnügen beim Lesen! :-)

[1] https://www.linuxjournal.com/article/3882

[Sheeva P. (sheevaplug)]

Vancouver schrieb:
> Sheeva P. schrieb:
>> Aber daß das "Tool" ihnen krudes Klammer-Gehacke -- das auf deutschen
>> und anderen Tastaturen obendrein regelmäßig zu lustigen Verrenkungen
>> führt -- vorschreibt, das nehmen sie klaglos hin?
>
> Genau. Deswegen verwendest du in Python sicher auch keine Dictionaries
> oder Listen, und Verschachtelungen davon schon gar nicht. Alles krudes
> Klammer-Gehacke. Echt blöd jetzt, dass die nicht mit Indents
> strukturiert sind.

Aber dann wären sie doch wieder unleserlich, weißt Du. Das ist aber 
eines der wichtigsten Designziele von Python, die Lesbarkeit des Code. 
Und das funktioniert ziemlich gut, weißt Du -- jedenfalls, wenn man 
einen Editor mit einer brauchbaren Unterstützung dafür hat. Mein GNU 
Emacs kann das jedenfalls perfekt, so benötige ich keinen Beautifier und 
keinen zusätzlichen Bearbeitungsschritt, bevor ich den Code committe.

Andererseits möchte ich Dir nicht verheimlichen, daß ich eine gewisse 
Genugtuung empfinde, daß Dir ganz offensichtlich die sachlichen 
Argumente ausgehen und Du deswegen versuchst, das Ganze ins Lächerliche 
zu ziehen. Ja, bitte entschuldige, ich bin ein furchtbar schlechter 
Mensch. :-)

> Sheeva P. schrieb:
>> Das ist doch nicht
>> Dein Ernst...
>
> Nee, war alles nur Spaß. Lassen wir's gut sein.

Klar, gerne. Können wir dann bitte auch zukünftig das dusselige Genöle 
über diese Sache mit dem Whitespace lassen, daß nahezu unweigerlich in 
jedem Python-Thread auftaucht, und das jeder Python-Nutzer schon bis zum 
Erbrechen gehört, gelesen, und meist auch schon mit Rauchzeichen, 
Morsecode und in ROT-13 erklärt bekommen hat -- üblicherweise von... 
Leuten, die ihrerseits keinerlei Erfahrung mit der Sprache haben? Das 
wäre doch echt mal cool, Dieter Nuhr zu folgen, findest Du nicht? Ich 
mein', echt jetzt: verspürst Du dasselbe Bedürfnis, jeden anzuhalten, 
der ein Auto in Goldmetallic fährt, um ihm zu erklären, daß der Wagen 
doch in orange oder blau viel cooler aussähe?

Siehst Du, die Sache ist manchmal ganz simpel. Python ist so, wie es 
ist. Ob Dich das jetzt stört oder nicht, interessiert keine Sau -- von 
den Python-Usern genau so wenig wie von den Nichtbenutzern. Du wirst mit 
Deinem hundertausendsten Genöle sicher nichts daran ändern, und wenn Du 
etwas daran ändern willst, dann benutz' doch einfach den handelsüblichen 
Mechanismus von Opensource-Software und biete einen Python-Fork an, der 
Deine geliebten Klammern und Verrenkungen erzwingt. Oh, natürlich gibt 
es sowas schon längst, aber weil es nicht von Dir herausragendem, 
großartigen und allwissenden Programmiergenie ist, benutzt es halt 
keiner... ok, natürlich könnte es auch sein, daß die Python-User mit der 
Sprache glücklich sind wie sie ist, aber die sind halt alle vollkommen 
dämlich und keine herausragenden Geistesgrößen und Überdeveloper so wie 
Du.

Andererseits könntest Du natürlich auch eine Middleware entwickeln, 
vielleicht mit lex  flexx und yacc  bison, textX, pyparsing -- you get 
the idea -- das jene häßlichen Klammerorgien, auf die Du anscheinend 
nicht verzichten kannst, in validen, aber zufällig formatierten 
Python-Code übersetzt. Damit hast Du sogar Deinen geliebten letzten 
Bearbeitungsschritt, das wäre doch super! Und, ach ja: wenn Du es mit 
Deinem verkrüppelten Dialekt in den nächsten 25 Jahren schaffst, auch 
nur näherungsweise so erfolgreich zu sein wie Python, dann verspreche 
ich, Deine Einwände ernst zu nehmen und für sinnvoll zu halten. Viel 
Erfolg und viel Glück dabei... Du wirst es brauchen. :-D

[Mark B. (markbrandis)]

Sheeva P. schrieb:

> Oh, ach ja: in einer realen Welt würde ich natürlich Getter (und eventuell
> Setter) mit einem Descriptor erzeugen und an die Klasse statt der Instanz
> binden. ;-D

Wobei eine standardmäßige Verwendung von Gettern und Settern dem 
Grundgedanken der Datenkapselung in der OOP zuwider läuft:
https://www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html

> Nein, im Ernst: wenn Du Fragen zu Python hast, bist Du mir natürlich
> jederzeit sehr herzlich willkommen.

Wenn Du mir vielleicht ein gutes Python-Tutorial oder Buch empfehlen 
könntest? Speziell für Leute die seit Jahren die Syntax von C/C++/Java 
gewohnt sind? :-)

[Sheeva P. (sheevaplug)]

Mark B. schrieb:
> Sheeva P. schrieb:
>
>> Oh, ach ja: in einer realen Welt würde ich natürlich Getter (und eventuell
>> Setter) mit einem Descriptor erzeugen und an die Klasse statt der Instanz
>> binden. ;-D
>
> Wobei eine standardmäßige Verwendung von Gettern und Settern dem
> Grundgedanken der Datenkapselung in der OOP zuwider läuft:

Was ist in Python eigentlich ein Deskriptor?

>> Nein, im Ernst: wenn Du Fragen zu Python hast, bist Du mir natürlich
>> jederzeit sehr herzlich willkommen.
>
> Wenn Du mir vielleicht ein gutes Python-Tutorial oder Buch empfehlen
> könntest? Speziell für Leute die seit Jahren die Syntax von C/C++/Java
> gewohnt sind? :-)

Na [1].


[1] https://docs.python.org/3/tutorial/

[Daniel -. (root)]

kleine Anmerkung noch bzw. Tipp für Anfänger und Fortgeschritene
googelt mal nach linter für python ... mypy, pyright, pytype

ich verwende pyright seit längerem und bin sehr zufrieden
mypy übersieht viele Fehler
mit pytype habe ich keine Erfahrung