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
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
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.
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...
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.
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.
Dachte ich auch aber nein hab scho so viel rumprobiert...
label2.pack(expand = 1)
^
IndentationError: unexpected indent
:
Bearbeitet durch User
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
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
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?
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
:
Bearbeitet durch User
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.
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 ^^´
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 ;-)
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?
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.
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
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()
1 | with open('C:\dateien\sortiment.txt', 'r') as ifh:
|
2 | 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"
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.
Eine Antwort zu meinem Problem statt dauernde Verachtung wäre hilfreich gewesen aber naja bin ja im Internet
Kev G. schrieb: > Eine Antwort zu meinem Problem Dein Problem wurde schon lange beantwortet. Die Einrückungen stimmen nicht.
Die Einrücken in Zeile 32 hab ich schon behoben dann kommt das geloescht nicht definiert ist
:
Bearbeitet durch User
>Die Einrücken in Zeile 32 hab ich schon behoben
Zeig mal (per hochgeladener Datei), was jetzt aktuell zur Diskussion
steht ...
:
Bearbeitet durch User
Kev G. schrieb: > Die Einrücken in Zeile 32 hab ich schon behoben > dann kommt das geloescht nicht definiert ist
1 | def aktion(self): |
2 | geloescht = False |
3 | if geloescht: |
Es ist ja in dem Scope, wo du es abfragst, auch nicht definiert. Nimm dir ein Python-Buch und lies es.
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. :-<
hidden symbol schrieb: > Und die nächste Abhängigkeit vom unsichtbaren Zeichen. :-< So ein Bullshit. Mit Klammern wäre das Ergebnis exakt gleich.
Beitrag #6634969 wurde vom Autor gelöscht.
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
:
Bearbeitet durch User
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"
@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.
1 | def aktion(self): |
2 | geloescht = False |
3 | if geloescht: |
4 | do_something() |
5 | # end if |
6 | # 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.
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.
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.
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.
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. ;->
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.
:
Bearbeitet durch Moderator
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?
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
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. :-<<<
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?
hidden symbol schrieb: > Dann warte ich mal auf die grünen und blauen > Zeichen und welche besonderen Spracheigenschaften > ihnen zugedacht werden. :-<<< ColorForth ist bekannt?
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.
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.
:
Bearbeitet durch User
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 ...
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.
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.
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.
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.
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. :-(
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?
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.
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.
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.
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.
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.
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 :)
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 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.
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.
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...
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).
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
1 | x = 1; |
2 | }
|
3 | }
|
4 | }
|
5 | }
|
6 | }
|
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?
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:
1 | bla() |
2 | bla() |
3 | bla() |
4 | blub() |
Na, wieviele Einrückunsebenen liegen zwischen dem letzten bla() und dem blub()? Eine? Zwei? Sieben? Und jetzt das:
1 | bla(); |
2 | bla(); |
3 | bla(); |
4 | }; |
5 | }; |
6 | }; |
7 | }; |
8 | blub(); |
9 | }; |
10 | }; |
Da schau an, es waren vier. Wer hätte das gedacht. Und es gibt sogar noch zwei danach.
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.
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:
1 | 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 :
1 | bla() |
2 | bla() |
3 | bla() |
4 | # end if |
5 | # end for z |
6 | # end for y |
7 | # end for x |
8 | 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.
:
Bearbeitet durch Moderator
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.
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.
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 .
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.
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 ;-)
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. > >
1 | > def aktion(self): |
2 | > geloescht = False |
3 | > if geloescht: |
4 | > do_something() |
5 | > # end if |
6 | > # end aktion() |
7 | > |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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
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:
1 | #!/usr/bin/env python
|
2 | # -*- coding: utf-8 -*-
|
3 | from functools import partial |
4 | from num2words import num2words |
5 | |
6 | class Yeah: |
7 | '''a class that dynamically creates its methods and names''' |
8 | def __init__(self, lang='de'): |
9 | self.value = None |
10 | def sv(self, v): self.value = v |
11 | for i in range(0, 20, 4): |
12 | fname = 'set'+ num2words(i, lang=lang).capitalize() |
13 | setattr(self, fname, partial(sv, self, i)) |
14 | delattr(self, 'setNull') |
15 | |
16 | def __repr__(self): |
17 | return '<{} value={}>'.format(self.__class__.__name__, self.value) |
18 | |
19 | if __name__ == '__main__': |
20 | y = Yeah(); print(y) |
21 | y.setVier(); print(y) |
22 | y.setZwölf(); print(y) |
23 | print([i for i in dir(y) if not i.startswith('_')]) |
Ausgabe:
1 | <Yeah value=None> |
2 | <Yeah value=4> |
3 | <Yeah value=12> |
4 | ['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
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
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? :-)
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/
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.