Nachdem im Nachbarthread über die Vorteile von Python diskutiert wurde
habe ich mir mal Tutorials angeschaut und bin gleich über eine Frage
gestolpert, deren Antwort sich mir nicht erschließt. Vielleicht hab ich
im Moment einfach auch nur ein Brett ...
Ein Beispiel von
https://www.programiz.com/python-programming/examples/prime-number
behandelt einen Primzahltest. Es geht um das erste else. Für mich muss
sich ein else eigentlich auf ein if beziehen. Im Beispiel scheint sich
von den Einrückungen her das else auf das for zu beziehen. Es leuchtet
mir nicht ein. Im Python Interpreter rechnet das Beispiel richtig und es
gibt keinen Syntax fehler. Irgendwas übersehe ich.
Vielleicht kann mich jemand erleuchten?!
Nun arbeite ich schon seit Ewigkeiten mit python und nun das:
Dieses Konstrukt kannte ich noch nicht.
Der Code ist korrekt.
Eine For Schleife kann einen else Zweig haben, der durchlaufen wird
wenn die Schleife nicht mit break unterbrochen wurde.
Siehe
https://book.pythontips.com/en/latest/for_-_else.html
Frohes lernen, es lohnt sich.
Gerhard schrieb:> for i in range(2,num):> if (num % i) == 0:> print(num,"is not a prime number")> print(i,"times",num//i,"is",num)> break> else:> print(num,"is a prime number")
Das Dümmste was ich jemals gesehen habe. Das ist einfach nur kriminell
;-)
Einfach else-Teil zu der for-Schleife direkt nach der if-Bedingung
zuordnen.
Sorry, aber das ist einfach nur krank. Und einige empfehlen noch Python
als erste Programmiersprache....
Sinn dahinter? schrieb:> Das Dümmste was ich jemals gesehen habe
Ich bin auch kein Fan von python.. nie gewesen
Und wenngleich ich dem Sinn hinter for-else auch nicht folgen kann
(hauptsächlich weil ich nicht will)
Muss ich doch zugestehen, dass python
schondoch auch seine Daseinsberechtigung hat.
Ich sehe auch kein Problem python zu lernen
(als erste zweite oder dritte Sprache ist da irrelevant)
die Tochter meines Kumpels (grad 10 geworden) ist recht flüssig
in python, und da andere Hochsprachen zumeist deutlich leichtere Syntax
nutzen,
möchte ich wetten -ohne es ausprobiert zu haben- dass sie C und derivate
recht leicht lesen und durchdringen kann,
und umlernen geht in dem Alter ja auch noch flott ;)
Ich mein.. in China lernen die Kinder auch zuerst Chinesisch, gell ;)
(und da ist die syntax nu auch sagen wir... öhm... "komplex")
'sid
Sinn dahinter? schrieb:> Gerhard schrieb:>> for i in range(2,num):>> if (num % i) == 0:>> print(num,"is not a prime number")>> print(i,"times",num//i,"is",num)>> break>> else:>> print(num,"is a prime number")>> Das Dümmste was ich jemals gesehen habe.
Leider ist dir beim Zitieren die Einrückung kaputt gegangen. So sieht es
tatsächlich seltsam aus. Im Original war das aber anders.
Sinn dahinter? schrieb:> Hans Müller schrieb:>> es lohnt sich.>> Was bringt dieses feature genau?
Schau dir den Link in dem Posting vor dir an. Dort ist ein Beipsiel
genannt.
Ich hätte mir schon öfters ein else bei Schleifen in C++ gewünscht,
allerdings mit anderer Bedeutung, nämlich so, dass der else-Zweig genau
dann durchlaufen wird, wenn die Schleife selbst nicht ausgeführt wird,
also die Schleifenbedingung schon von Anfang an nicht erfüllt war.
Gerhard schrieb:> if num > 1:> # check for factors> for i in range(2,num):> if (num % i) == 0:> print(num,"is not a prime number")> print(i,"times",num//i,"is",num)> break> else:> print(num,"is a prime number")
Ganz ehrlich, das soll einfacher lesbar sein als:
Ben S. schrieb:> Gerhard schrieb:>> if num > 1:>> # check for factors>> for i in range(2,num):>> if (num % i) == 0:>> print(num,"is not a prime number")>> print(i,"times",num//i,"is",num)>> break>> else:>> print(num,"is a prime number")>> Ganz ehrlich, das soll einfacher lesbar sein als:>>
1
> if num > 1 {
2
> for i in range(2,num){
3
> if (num % i) == 0{
4
> print(num,"is not a prime number")
5
> print(i,"times",num//i,"is",num)
6
> break
7
> }
8
> }
9
> else{
10
> print(num,"is a prime number")
11
> }
12
> }
13
>
>> Erschließt sich mir nicht.
<ironie>
Na selbstverständlich sind Leerzeichen und Einrückungen deutlich
leichter und viel eindeutiger lesbar als paarweise { und }.
Und vor allem bis man die Zeichen { und } auf der Tastatur findet, das
ist sehr mühsam. Nicht zu vergessen dass der Code um 4 Zeilen länger
wird. Schrecklich...
</ironie off>
Damit es kein Mißverständnis gibt: ich mag Python vom Konzept und den
Bilbiotheken und was man alles damit machen kann. Aber die
Strukturierung durch Leerzeichen und Tabs hat bisher erfolgreich
verhindert dass ich mehr als eine paar Handvoll Zeilen in Python
geschrieben habe. Dagegen habe ich hundertausende in C oder Objective-C
herumliegen. Manche auch im Linux-Kernel.
Rolf M. schrieb:> Leider ist dir beim Zitieren die Einrückung kaputt gegangen. So sieht es> tatsächlich seltsam aus. Im Original war das aber anders.
Also in meinem Browser (Vivaldi) wird der zitierte Code im ersten
Posting richtig dargestellt, genau wie im verlinkten Beispiel. Oder ich
hab Tomaten ...
Gerhard schrieb:> Also in meinem Browser (Vivaldi) wird der zitierte Code im ersten> Posting richtig dargestellt, genau wie im verlinkten Beispiel. Oder ich> hab Tomaten ...
Herrlich! Mit Klammern gäbe es jetzt absolut keine Probleme oder
Diskussion.
Nikolaus S. schrieb:> Damit es kein Mißverständnis gibt: ich mag Python vom Konzept und den> Bilbiotheken und was man alles damit machen kann. Aber die> Strukturierung durch Leerzeichen und Tabs hat bisher erfolgreich> verhindert dass ich mehr als eine paar Handvoll Zeilen in Python> geschrieben habe.
So siehts aus. Es ist ein riesen Manko von C/C++, dass es keine
Bibliotheksdatenbank gibt. Andererseits ist das auch gut so, da es die
einfache Struktur von C hervorhebt. Wenn man dort eine gewisse
Funktionalität haben möchte geht man ins Internet, schaut sich
verschiedene Bibliotheken an, ladet diese runter und probiert diese aus.
Boost etc. sind hierfür keine vollwertigen Alternativen. Trotzdem setze
ich python nur für einfache Scripte ein.
Ben S. schrieb:> Herrlich! Mit Klammern gäbe es jetzt absolut keine Probleme oder> Diskussion.
Hat irgendeiner von euch auch so einen Editor? Da wenn man auf eine
Klammeer klickt, zeigt er die zugehörige Andere?
Manchmal hat man ja Zeifel ob der Einrückung und dann find ich das ganz
sinnvoll.
Ich zweifle aber an, dass es einen Editor gibt, der auf Nicht-Klammern
genauso reagiert.
Sinn dahinter? schrieb:> Das Dümmste was ich jemals gesehen habe. Das ist einfach nur kriminell> ;-)>> Einfach else-Teil zu der for-Schleife direkt nach der if-Bedingung> zuordnen.
Das ist aber nicht dasselbe.
Wenn du das erkannt hast (notfalls einfach ausprobieren), kennst du auch
den Sinn hinter dem for-break-else.
Ich persönlich finde das for-break-else äußerst praktisch, um nach einer
Suche mit for und break bei negativem Ausgang eine andere Folgeaktion
als bei positivem Ausgang auszuführen. Dieser Fall tritt bei mir sehr
häufig auf. Das hätte ich auch gerne in C und C++, nur dass es dort aus
Abwärtskompatibilitätsgründen leider nicht mehr nachträglich hinzugefügt
werden kann.
Ohne das for-break-else behilft man sich üblicherweise mit einem Flag,
das den Ausgang der Suche anzeigt, und einer zusätzlichen if-Abfrage.
Das funktioniert zwar, ist aber umständlich und unschön.
Ben S. schrieb:> Herrlich! Mit Klammern gäbe es jetzt absolut keine Probleme oder> Diskussion.
Dass das Problem überhaupt nicht mit der Einrückung zusammenhängt, hat
der TE schon nach 5 Minuten selber erkannt:
Gerhard schrieb:> Zu schnell gepostet, Frage hat sich erledigt.
Schon im Eröffnungsbeitrag hat er die Einrückung richtig interpretiert,
nur kannte er da das for-break-else-Konstrukt noch nicht:
Gerhard schrieb:> Im Beispiel scheint sich von den Einrückungen her das else auf das for> zu beziehen.
Yalu X. schrieb:> Ich persönlich finde das for-break-else äußerst praktisch, um nach einer> Suche mit for und break bei negativem Ausgang eine andere Folgeaktion> als bei positivem Ausgang auszuführen.
Ich empfinde das etwas seltsam, aus einer for-Schleife mit gegebenen
Grenzen mit einem Break rauszugehen. Sieht für mich eher nach "im
Nachhinein reingefrickelt" aus. Ich würde das so schreiben und damit
beide Kriterien (break / kein break) lesbar behandeln:
1
intupper=10;
2
intiter=0;
3
4
for(;;){
5
// rechne irgendwas
6
7
if(unexpectedHappened){
8
printf("Das ist jetzt leider so");
9
break;
10
}
11
12
iter++;
13
if(iter>=upper){
14
printf("Obergrenze erreicht");
15
// mach was
16
break;
17
}
18
}
Begründung:
So sieht man, dass man in der Unedlichkeitsschleife nach break suchen
muss, anders geht es nicht.
Beide Fälle werden in der Schleife behandelt und der zugehörige Code ist
in der Schleife und nicht ausserhalb.
Beide Fälle sind so überhaupt erst behandelbar. Das Python-Konstrukt ist
halbherzig und kann nur den break-Fall in der for-Schleife behandeln,
aber nicht den Fall mit regulären Ende.
Yalu X. schrieb:> Ich persönlich finde das for-break-else äußerst praktisch, um nach einer> Suche mit for und break bei negativem Ausgang eine andere Folgeaktion> als bei positivem Ausgang auszuführen. Dieser Fall tritt bei mir sehr> häufig auf. Das hätte ich auch gerne in C und C++,
Ja, in C muss man immer ein weiteres if() unter der for-Schleife
verwenden, um das for-else nachzubilden. Kommt bei mir auch desöfteren
vor.
Ja, man könnte natürlich auch goto statt break verwenden:
1
for(.....)
2
{
3
...
4
gotomybreak;// statt break
5
}
6
// hier der else Code
7
mybreak:
8
// hier geht's weiter
Damit geht's auch effizient in C - ohne weiteres if(). Aber so machen
würde ich das nicht ;-)
Nick M. schrieb:> Beide Fälle sind so überhaupt erst behandelbar. Das Python-Konstrukt ist> halbherzig und kann nur den break-Fall in der for-Schleife behandeln,> aber nicht den Fall mit regulären Ende.
Bei typischer Python-Iteration ohne Laufindex lässt sich (in der
Schleife) nicht ohne Weiteres erkennen, dass das Ende erreicht ist. Da
ist diese Spielart mit `else` nützlich:
Nick M. schrieb:> Ich würde das so schreiben und damit beide Kriterien (break / kein> break) lesbar behandeln:> ...
Ja, das finde ich auch in Ordnung, da man damit beide Schleifenabbrüche
ohne eine zusätzliche Flag-Variable behandeln kann.
Auf der anderen Seite empfinde ich es aber auch als vorteilhaft, wenn
man gleich im Schleifenkopf erkennen kann, worüber überhaupt iteriert
wird. Diese Information geht in deinem Beispiel leider etwas verloren.
Man kann hier nicht einmal auf Anhieb erkennen, dass die Schleife
terminiert. Im Beispiel des TE hingegen wird sofort klar, dass die
Schleife maximal num-2 Durchläufe macht.
> Das Python-Konstrukt ist halbherzig und kann nur den break-Fall in der> for-Schleife behandeln, aber nicht den Fall mit regulären Ende.
Ja, schöner wäre es wenn beide Fälle außerhalb der Schleife behandelt
werden könnten.
Das geht in Python sogar, wenn der Schleifenrumpf zu einem einzelnen
Ausdruck zusammengefasst und damit in als Generator realisiert werden
kann. Der Code des TE sieht dann so aus:
1
n = 407
2
isPrime = n > 1 and all(n % i > 0 for i in range(2, n))
3
print(f"{n} is {['not ', ''][isPrime]}a prime number")
Ok, Die letzte Zeile habe ich, um den Whitespace-Einrückungsgegnern
entgegenzukommen, vielleicht etwas arg geschrumpft ;-)
Die zweite Zeile (die Überprüfung, ob n prim ist) ist übrigens ein
schönes Beispiel für die Ausdrucksstärke von Python. Die Anweisung liest
sich fast wie die mathematische Definition der Primzahleigenschaft. So
etwas kennt man sonst vor allem aus Funktionalsprachen.
Gerhard schrieb:> Rolf M. schrieb:>> Leider ist dir beim Zitieren die Einrückung kaputt gegangen. So sieht es>> tatsächlich seltsam aus. Im Original war das aber anders.>> Also in meinem Browser (Vivaldi) wird der zitierte Code im ersten> Posting richtig dargestellt, genau wie im verlinkten Beispiel. Oder ich> hab Tomaten ...
Im ersten Posting ja, aber nicht in dem Zitat, auf das ich geantwortet
habe, in Beitrag "Re: Frage zu Python if else Einrückung". Dort ist
bei mir das for falsch eingerückt, so dass das else einrückungsmäßig
genau zwischen for und if steht.
Ben S. schrieb:> Ganz ehrlich, das soll einfacher lesbar sein
Nö, hat das einer behauptet? Es ist aber auch nicht schwerer lesbar,
aber es gibt keine Klammern, die nicht zur Einrückung passen könnten.
Ben S. schrieb:> Herrlich! Mit Klammern gäbe es jetzt absolut keine Probleme oder> Diskussion.
Dast ist natürlich das Killerargument, dass auf ganz bestimmte Art
kaputte Forums-Zitate den Code nicht verfälschen.
Nick M. schrieb:> Hat irgendeiner von euch auch so einen Editor? Da wenn man auf eine> Klammeer klickt, zeigt er die zugehörige Andere?> Manchmal hat man ja Zeifel ob der Einrückung und dann find ich das ganz> sinnvoll.
Du meinst, du siehst, wie es eingerückt ist, kannst aber nicht so
schnell erkennen, ob die Klammern auch dazu passend gesetzt sind?
> Ich zweifle aber an, dass es einen Editor gibt, der auf Nicht-Klammern> genauso reagiert.
Da sich bei Python das Problem gar nicht ergibt, braucht man das nicht.
Frank M. schrieb:> Damit geht's auch effizient in C - ohne weiteres if(). Aber so machen> würde ich das nicht ;-)
Warum eigentlich genau? Weil du es wirklich schlechter lesbar findest
oder nur weil goto halt als böse glit.
Nick M. schrieb:> Ben S. schrieb:>> Herrlich! Mit Klammern gäbe es jetzt absolut keine Probleme oder>> Diskussion.>> Hat irgendeiner von euch auch so einen Editor? Da wenn man auf eine> Klammeer klickt, zeigt er die zugehörige Andere?> Manchmal hat man ja Zeifel ob der Einrückung und dann find ich das ganz> sinnvoll.> Ich zweifle aber an, dass es einen Editor gibt, der auf Nicht-Klammern> genauso reagiert.
Schau dir mal Visual Studio Code an. Da zeigt es die Einrückung gut an,
man kann auch Einrücken ausblenden (siehe Foto 2).
P.S.: ist aus einem Übungsbeispiel und hat keinen wirklichen sinn im
Code.
afran schrieb:> Da ist diese Spielart mit `else` nützlich:
Ich hab schon ein rein sprachliches Problem mit dem for-else.
Else was? Else warum? Da muss was anderes her, z.B. forbreak (nehme
gerne andere Vorschläge an), dann ist klar was passiert ist und warum in
den Zweig gegangen wird.
Nochmal, das Python-Konstrukt ist halbherzig, nein, es ist
drittelherzig.
Es gibt drei Fälle:
1.) die Schleife wird nicht mal begonnen, weil es 0 Elemente gibt
2.) die Schleife wird durch break vorzeitig verlassen
3.) die Schleife wird ganz normal durchlaufen.
Ich hatte geglaubt mich zu erinnern, dass das in Eiffel irgendwie
raffinierter gehandhabt wird, ist aber nicht ganz so umsetzbar. Da gibt
es zwar "contracts" die sicherstellen, dass Grenzen immer eingehalten
werden, bringt aber hier nix.
Zurück zu Python:
Das for-else fängt nur eine der drei Möglichkeiten ab und ist sprachlich
sehr fragwürdig (man kann es nur auswendig lernen). Knuth würde
aufheulen.
Ich würde mir ein for-forbreak-forend-forempty forstellen (SIC :-)) )
Hier mein C-Konstrukt, erweitert um den 3. Fall
1
constintupper=10;
2
intiter=0;
3
4
for(;;){
5
// case 1.) empty loop
6
if(iter>=upper){
7
printf("empty loop");
8
// do something 1
9
break;
10
}
11
12
// ---- loop core
13
// do something
14
15
// case 2.) premature end
16
if(unexpectedHappened){
17
printf("exceptional end of loop");
18
// do something 2
19
break;
20
}
21
22
iter++;
23
// case 3.) natural end
24
if(iter>=upper){
25
printf("normal end of loop");
26
// do something 3
27
break;
28
}
29
}
Den Fall 1.) kann man auch leicht ausserhalb der Schleife stellen wg.
kleinen Geschwindigkeitsvorteil. Ich habs aus systematischen Gründen
reingestellt. Gäbe es ein for-forbreak-forend-forempty, dann wäre das
maximal leserlich:
1
for(i=0;i<10;i++){
2
// Normal loop stuff goes here
3
4
5
forempty{
6
printf("empty loop");
7
}
8
forbreak{
9
printf("exceptional end");
10
}
11
forend{
12
printf("normal end");
13
}
14
}
Ich würde das forempty, forbreak und forend in den Block for-Schleife
stellen, so könnte man prägnantere begriffe verwenden. empty, fbreak
end.
Das ist meine Meinung warum das for-else-Konstrukt in Python nicht zu
Ende gedacht ist. Man kann gerne diskutieren, wo die
forempty-forbreak-forend hingehören, das ist nur ein Vorschlag. Bestimmt
hat jemand eine bessere Idee.
Ich habs hier als C-code dargestellt, weil das wohl jeder lesen kann.
Simi S. schrieb:> Schau dir mal Visual Studio Code an. Da zeigt es die Einrückung gut an,
Ich kenn die Linien schon, das ist nix neues.
Wenn ich die mal verfolgen muss, wird mir manchmal schwindlig. Ist wohl
ein Hinweis dafür, dass ich den Code aufteilen soll. :-)
Nick M. schrieb:> Zurück zu Python:> Das for-else fängt nur eine der drei Möglichkeiten ab und ist sprachlich> sehr fragwürdig (man kann es nur auswendig lernen). Knuth würde> aufheulen.> Ich würde mir ein for-forbreak-forend-forempty forstellen (SIC :-)) )
Als ich das erste Mal das for-else-Konstrukt sah dachte ich auch
zuallererst, der else-Teil wird ausgeführt für den Fall dass der
Schleifen-Rumpf kein einziges Mal durchlaufen wird (die Abbruchbedingung
also schon zu beginn unwahr ist).
War irgendwie intuitiver.
Hat mich dann auch überrascht als ich sah was hier wirklich geschieht.
Jetzt sollte man beim Anwenden einer Programmiersprache freilich mehr
aufs Manual als auf Intuition vertrauen.
Dennoch: das recyclen von Schlüsselwörtern unter Belegung selbiger mit
unterschiedlicher Funktionalität finde ich ungeschickt.
Erinnert etwas an C und den Umgang mit static.
Yalu X. schrieb:> Diese Information geht in deinem Beispiel leider etwas verloren.> Man kann hier nicht einmal auf Anhieb erkennen, dass die Schleife> terminiert.
Iterator geht verloren. OK, sieht man nicht im "for (;;)", daher hab ich
die Laufvariable auch absichtlich "interator" genannt. Fieser Trick. ;-)
Und dass die Schleife terminieren muss, ist eigentlich
Grundvoraussetzung der Schleife.
Wenn ich eine Schleife hab die tatsächlich nie terminiert, mach ich das
so:
1
#define HELL_FREEZES_OVER true
2
3
while(HELL_FREEZES_OVER){
4
// need more coal
5
}
Ja, so mach ich das, dann haben Nachfolger noch was zu lachen.
Yalu X. schrieb:> Das geht in Python sogar, wenn der Schleifenrumpf zu einem einzelnen> Ausdruck zusammengefasst und damit in als Generator realisiert werden> kann. Der Code des TE sieht dann so aus:> isPrime = n > 1 and all(n % i > 0 for i in range(2, n))
Sorry, aber so ein code verursacht Brechreiz bei mir. Da könnte ich auch
gleich den verstaubten K&R rausziehen, und nach der Vorlage möglicht
sinnleere ein-Buchstaben-Variablennamen verwenden und alles in eine
Zeile reinquetschen.
Du würdest von mir eine mitm Tatzenstecken auf die Finger bekommen. ;-)
Nick M. schrieb:>> isPrime = n > 1 and all(n % i > 0 for i in range(2, n))>> Sorry, aber so ein code verursacht Brechreiz bei mir. Da könnte ich auch> gleich den verstaubten K&R rausziehen, und nach der Vorlage möglicht> sinnleere ein-Buchstaben-Variablennamen verwenden und alles in eine> Zeile reinquetschen.> Du würdest von mir eine mitm Tatzenstecken auf die Finger bekommen. ;-)
Python bietet sehr viele sehr mächtige Spracheigenschaften um viel
Funktionalität in wenig Code zu pressen.
Ich stolpere regelmäßig auf stackoverflow über so Konstrukte und
verwende sie dann auch gerne mal. Schon interessant was teilweise alles
geht.
Wichtig ist aber ein mehrzeiliger Kommentar drüber damit ich auch
nächsten Monat noch weiß was da genau passiert.
Vielleicht hätte Guido anstelle von Einrückungen Kommentare erzwingen
sollen ;-)
Mal nebenbei gefragt: Daraus folgt jetzt doch, dass die for- und
while-Schleife nicht mehr gleich sind?
Oder gibt es jetzt auch while-break-Schleife? Das ist so absurd.
Le X. schrieb:> Jetzt sollte man beim Anwenden einer Programmiersprache freilich mehr> aufs Manual als auf Intuition vertrauen.
Nein, die Schlüsselwörter müssen treffend und prägnant sein. Ansonsten
schlag ich zur Strafe vor sie einfach fortlaufend und zusammenhangslos
mit a, b, c, ... zu benamsen.
Ich sags zum wiederholten Male:
Lest "literate Programming" von Knuth. Das C hier und Python und was
auch immer hat damit nix zu tun, leider. Wenn man aber z.B. Doxygen im
code wirklich umsetzt, dann kommt man der Sache schon näher.
Nick M. schrieb:> die Laufvariable auch absichtlich "interator" genannt. Fieser Trick. ;-)
LOL
"iterator" natürlich. Auch wenn er ein int ist.
Obwohl, doch ein recht treffender Name. Werd ich mir merken.
Le X. schrieb:> Wichtig ist aber ein mehrzeiliger Kommentar drüber damit ich auch> nächsten Monat noch weiß was da genau passiert.> Vielleicht hätte Guido anstelle von Einrückungen Kommentare erzwingen> sollen ;-)
ROFT!
Der war jetzt wirklich gut!
Ich plädiere immer für leserlichen Code. Wenn man das nur mit
Kommentaren hinbekommt -für eine Zeile wie im Beispiel-, dann ist das
jämmerlicher code.
Wenn man so eine Codekompresse in 3 Zeilen aufbricht, sollte ein guter
compiler das genauso kompakt hinbekommen wie das Kompressat selbst.
Und wenn nicht: Mir wurscht, wenns an den 24 ps scheitert hab ich ganz
wo anders versagt.
Nick M. schrieb:> Ich würde das forempty, forbreak und forend in den Block for-Schleife> stellen,
Ich nicht, denn sie sind nicht Teil des Code, der als Schleife
ausgeführt wird.
> so könnte man prägnantere begriffe verwenden. empty, fbreak> end.
Sehr ungünstig. Dann wird jeder Code inkompatibel, in dem eines dieser
Wörter als Name vorkommt. Mit Schlüsselwörtern sollte man in
Sprachdefinitionen immer sehr sparsam umgehen.
Nick M. schrieb:> Wenn ich eine Schleife hab die tatsächlich nie terminiert, mach ich das> so:> #define HELL_FREEZES_OVER true>> while (HELL_FREEZES_OVER) {> // need more coal> }>> Ja, so mach ich das, dann haben Nachfolger noch was zu lachen.
Ich schreibe ganz langweilig for (;;), denn for hat den Vorteil, dass
man damit genau das ausdrücken kann, was man in dem Fall will, nämlich
eine Schleife ohne Bedingung. Bei while ist man gezwungen, immer was als
Bedingung hinzuschreiben.
Übrigens hast du wohl nicht ganz die Bedeutung von "hell freezes over"
verstanden, denn da geht es nicht darum, dass man etwas tut, solange
die Hölle zufriert, sondern bis sie zufriert.
Nick M. schrieb:> Ich plädiere immer für leserlichen Code. Wenn man das nur mit> Kommentaren hinbekommt -für eine Zeile wie im Beispiel-, dann ist das> jämmerlicher code.
Da muss ich zu einem gewissen Grad zustimmen. Code sollte sich möglichst
selbst dokumentieren. Wenn man einen Kommentar braucht, um zu verstehen,
was der Code überhaupt macht, sollte man sich immer überlegen, ob man
den Code auch so schreiben kann, dass der Kommentar überflüssig wird -
oder einen guten Grund haben, warum man das nicht getan hat.
Nick M. schrieb:>> isPrime = n > 1 and all(n % i > 0 for i in range(2, n))>> Sorry, aber so ein code verursacht Brechreiz bei mir.
Oh nein, nicht schon wieder. Du hast im parallel Thread ein paar
interessante Punkte beschrieben, aber Du disqualifizierst Dich immer
wieder mit deinen Stammtisch Ausdrücken. Warum?
Diese Zeile verstehe ich sofort. Hat man das Prinzip verstanden, ist es
sehr leicht lesbar. Das fällt mir mit der Meta-Template Programmierung
in C++ viel schwerer.
Man muss List Comprehension ja nicht benutzen, wenn man nicht mag.
Aber nur weil Du es nicht gewohnt bist soll es schlecht sein?
Rolf M. schrieb:> Sehr ungünstig. Dann wird jeder Code inkompatibel,
Ist übrigens ein Grund, warum man die Syntax sich von Anfang an
überlegen sollte. Haben viele Sprachen recht erfolgreich umgesetzt.
Gibts bei Python nicht zwei Versionen die nicht kompatibel sind?
Rolf M. schrieb:> in dem eines dieser> Wörter als Name vorkommt. Mit Schlüsselwörtern sollte man in> Sprachdefinitionen immer sehr sparsam umgehen.
Was dann zu der sinnfreien Verwendung von if-else führt?
Wohingegen man schon beim elif, is, or, and, not den minder sparsamen
Umgang erfolgreich exerziert hat.
Rolf M. schrieb:> Übrigens hast du wohl nicht ganz die Bedeutung von "hell freezes over"> verstanden,
Doch, ganz sicher. Lies den Kommentar.
Nick M. schrieb:>> isPrime = n > 1 and all(n % i > 0 for i in range(2, n))>> Sorry, aber so ein code verursacht Brechreiz bei mir.
Hmm, vielleicht haben wir diesbezüglich leicht verschiedene Denkweisen.
Für mich liest sich die obige Codezeile direkt so:
"Eine Zahl n ist genau dann prim, wenn sie größer als 1 ist und für
alle 2≤i<n nicht durch i teilbar ist."
Hier ist die Zuordnung zwischen Prosatext und den Codeelementen:
1
Eine Zahl n ist genau dann prim, wenn sie größer als 1 ist und
2
\_________________/ \__________/ \_/
3
isPrime = n > 1 and
4
5
für alle 2 ≤ i < n nicht durch i teilbar ist.
6
\_/ \__/ \_______/ \_______________________/
7
for all i in range(2,n) n % i > 0
Lediglich die Reihenfolge der einzelnen Elemente ist im Pythoncode etwas
anders als im Prosatext.
Selbst ohne Kommentar und wenn der Variablenname isPrime nicht darauf
hinweisen würde, dass es um Primzahlen geht, würde ich auf einen Blick
erkennen, was hier gemacht wird.
Auch in mathematischen Symbolen geschrieben sieht das nicht viel anders
aus:
Um noch deutlicher herauszustellen, dass die Variable n Gegenstand der
Prüfung ist, würde ich den Ausdruck in eine Funktion mit Argument n
packen:
1
def isPrime(n):
2
return n > 1 and all(n % i > 0 for i in range(2, n))
Durch den Funktionsnamen isPrime ist die Funktion IMHO auch ohne
weitere Kommentare ausreichend dokumentiert. Zumindest meine Kollegen
(die zugegebenermaßen alle Akademiker sind) würden das sofort verstehen.
Wird das Ganze hingegen als for-Schleife mit if, break und else
ausgeschrieben, brauche ich deutlich länger, um den Sinn des Codes zu
erfassen.
Klaus H. schrieb:> aber Du disqualifizierst Dich immer> wieder mit deinen Stammtisch Ausdrücken. Warum?
Damit Leute wie du die Chance zum persönlichen Angriff bekommen?
Ich kann dir gleiche Zeilen in C irgendwoher zitieren und auch bei denen
bekomm ich Brechreiz. Ich programmiere nicht, um damit im Obfuscated
Contest zu gewinnen. Sondern um sauberen, lesebaren, wartbaren und
funktionierenden Code zu bekommen.
Hier kannst du suchen, ob für dich unerträgliches dabei ist. In C und
Python:
http://p-nand-q.com/programming/obfuscation/python/more.htmlhttps://ioccc.org/
Yalu X. schrieb:> Wird das Ganze hingegen als for-Schleife mit if, break und else> ausgeschrieben, brauche ich deutlich länger, um den Sinn des Codes zu> erfassen.
Sehe ich auch so. Zumal bei der funktionalen Schreibweise auch klar ist
(*), dass der Code keine Seiteneffekte ausführt.
Im Allgemeinen bin ich persönlich großer Fan funktionaler Ausdrucksweise
und empfinde diese (nach Überwindung anfänglicher Berührungsängste) als
deutlich angenehmer zu lesen und auch besser zu warten als die gleichen
Funktionen in klassisch-imperativer Programmierung.
(*) In aller Regel; manche Sprachen forcieren das mehr als andere.
Nick M. schrieb:> Ich programmiere nicht, um damit im Obfuscated> Contest zu gewinnen. Sondern um sauberen, lesebaren, wartbaren und> funktionierenden Code zu bekommen.
Ok, entschuldige mein "disqualifiziere", ich nehme es zurück.
Mein Ziel ist kein Anderes als Deines.
Ich persönlich halte den obigen Ausdruck von Yalu als
sauberen, lesebaren, wartbaren und funktionierenden Code.
Nick M. schrieb:> Rolf M. schrieb:>> Sehr ungünstig. Dann wird jeder Code inkompatibel,>> Ist übrigens ein Grund, warum man die Syntax sich von Anfang an> überlegen sollte.
Naja, wie das eben so ist. Im Laufe von fast 30 Jahren kann schon mal
der eine oder andere Wunsch nach einem Feature aufkommen, an das man
damals Anfang der 90er noch nicht gedacht hat.
> Haben viele Sprachen recht erfolgreich umgesetzt.> Gibts bei Python nicht zwei Versionen die nicht kompatibel sind?
Ja, und es hat etliche Jahre gedauert, bis dann alles, was darauf
basiert auch langsam mal umgestellt wurde, bzw. dauert dieser Vorgang
weiterhin an.
Meistens sind auf Linux-Systemen immer noch beide Versionen parallel
installiert. Sowas will man sich nicht antun, nur damit man ein
schöneres Wort hat.
Viel krasser ist das Thema der Vermeidung von Schlüsselwörtern übrigens
in C. Deshalb wurde z.B. der boolesche Typ nicht bool, sondern _Bool
genannt, genau wie dessen Werte _True und _False. Namen, die mit
Unterstrich gefolgt von einem Großbuchstaben beginnen, sind für den
Compiler reserviert, können also bei einem konformen Programm nicht
kollidieren. Und dann hat man per Header <stdbool.h> ein mapping auf die
gewohnten Bezeichnungen gemacht. So kann Code, der selbst diese Wörter
definiert, immer noch fehlerfrei übersetzt werden, indem die einfach
dieses include nicht nutzen.
> Was dann zu der sinnfreien Verwendung von if-else führt?> Wohingegen man schon beim elif, is, or, and, not den minder sparsamen> Umgang erfolgreich exerziert hat.
Das ist eben eine Abwägung. Und or, and, not sind ja nun als
Schlüsselwörter auch nicht ungewöhnlich, wenn man sich mal abseits von
Sprachen mit C-artiger Syntax umschaut. elif kommt auch in vielen
Skriptsprachen und auch im C-Präprozessor als #elif vor, ist also auch
nicht gerade ein unbekannter.
Klaus H. schrieb:> Ich persönlich halte den obigen Ausdruck von Yalu als> sauberen, lesebaren, wartbaren und funktionierenden Code.
OK, das ist eine Diskussionsgrundlage.
Ich kenn ja kein Python, daher schaut das wohl für mich verwirrend
aus.
Jede Sprache hat Idioms (wie bei gesprochenen Sprachen auch). Wenn das
ein Idiom in Python ist das der halbwegs Geübte auf einen Blick erkennt
und zerlagen kann, dann ist das einfach so.*)
In C ist das z.B. das geliebte for (;;). Ist aber auch wirklich schnell
zu lesen. Ein Anfänger strauchelt da drüber.
*) Würde mich aber dennoch über die 2 oder 3-zeilige Version hier zum
Vergleich freuen.
Nick M. schrieb:> Ist übrigens ein Grund, warum man die Syntax sich von Anfang an> überlegen sollte.
Ich glaube inzwischen haben alle mitbekommen das du Python nicht magst
und es ist pöse, weil es nicht deinen Vorstellungen entspricht und die
Erfinder sich keine Gedanken machen und überhaupt, nicht die hellsten
Kerzen waren. So verstehe ich dich zumindest, wenn ich mir deine
Beiträge zum Thema Python anschaue.
Alles schlecht, grausam, zum erbrechen, schwachsinnig...
Andere Frage... Warum befasst du dich mit etwas du scheisse findest?
Kann man Texte nicht auch Diplomatischer verfassen? Warum so aggressive
Worte?
Klaus H. schrieb:> Ok, entschuldige mein "disqualifiziere", ich nehme es zurück.> Mein Ziel ist kein Anderes als Deines.
Nur um das unmissverständlich zu beantworten:
Angenommen!
+
Dann sind wir uns da auch absolut einig.
Also selbst als großer Python-Freund muss ich zugeben, dass das
for...else-Konstrukt ein Krampf ist. Ja, es spart ein bisschen
Codezeilen. Aber es ist absolut unintuitiv. Ich sehe das alle paar
Monate mal, und jedes Mal muss ich nachschlagen was genau das jetzt
nochmal macht. Auf solche Sprachfeatures sollte man m.E. lieber
verzichten. Allgemein bin ich wie Yalu eher ein Fan des funktionalen
Stils. Für Schleifen habe ich selten Bedarf.
Zur Frage, warum hier else als Schlüsselwort benutzt wird, obwohl es
kein zugehöriges if gibt.
Die Antwort: Das zugehörige if existiert tatsächlich, allerdings ist
es nicht direkt sichtbar, sondern im while bzw. for verborgen.
Eine while-else-Schleife sieht allgemein so aus:
1
while condition: # gewöhnliche
2
# loop body # Schleife
3
4
else: # optionaler
5
# else body # else-Zweig
Das ist äquivalent zu folgendem Pseudocode (pseudo deswegen, weil Python
von Hause aus kein goto hat):
1
loop: #
2
if condition: # gewöhnliche
3
# loop body # Schleife
4
goto loop #
5
6
else: # optionaler
7
# else body # else-Zweig
Der else-Zweig sieht im realen Code (oben) genauso aus wie im Pseudocode
(unten) und ist ganz eindeutig einem (im realen Code impliziten) if
zugeordnet.
Bei der for-else-Schleife verhält es sich ganz ähnlich, nur dass dort
zusätzlich in jedem Schleifendurchlauf das jeweils nächste Element aus
der übergebenen Sequenz extrahiert wird und die condition sich aus dem
Erfolg oder Misserfolg dieser Extraktion ergibt.
Insgesamt ist Python IMHO eine sehr durchdachte Sprache. Die meisten der
wenigen konzeptionellen Fehler wurden in Python 3 behoben, allerdings
ging das nur auf Kosten der Abwärtskompatibilität. Dies wird von einigen
heftig kritisiert, weil sie dadurch ihre alte Software anpassen müssen.
Das bedeutet zwar in den meisten Fällen nicht den Riesenaufwand, aber
ärgerlich ist es trotzdem.
Bei C++ hingegen wird um jeden Preis versucht, Abwärtskompatibilität zu
älteren Versionen und großteils sogar zu C zu garantieren. Das Ergebnis
sind jede Menge Altlasten, die über viele Jahrzehnte mitgeschleppt
werden und die Sprache unnötig komplex machen. Insbesondere Anfänger und
Gelegenheitsprogrammierer haben ihre Schwierigkeiten, zu erkennen,
welche C++-Features veraltet sind und deswegen nicht mehr verwendet
werden sollten. Das ist ebenfalls ärgerlich.
Die von Anfang an perfekte Programmiersprache gibt es halt leider nicht.
Andreas schrieb:> Allgemein bin ich wie Yalu eher ein Fan des funktionalen> Stils. Für Schleifen habe ich selten Bedarf.
Ein angenehmer Nebeneffekt davon ist, dass die Verschachtelungstiefe
reduziert wird, man weniger Einrückungen braucht und deswegen die
Diskussion um die Strukturierung Whitespace mehr in den Hintergrund
rückt. Auch Haskell verwendet Einrückungen als syntaktisches Element,
dort wird aber kaum darüber diskutiert, weil das in der Praxis wirklich
kein Problem darstellt, dafür aber stark zur Ästhetik des Programmcodes
beiträgt. Man darf dort optional auch mit geschweiften Klammern und
Semikola strukturieren, aber niemand (außer vielleicht der eine oder
andere Codegenerator) macht von dieser Möglichkeit Gebrauch.
Auch in anderen imperativen Sprachen wie Rust, C# und C++ ist ja ein
leichter Trend zur funktionalen und damit auch "schleifen- und
verschachtelungsarmen Programmierung" erkennbar.
Ben S. schrieb:> Ganz ehrlich, das soll einfacher lesbar sein als:> [...]> Erschließt sich mir nicht.
Geschmacks- und Gewohnheitssachen müssen sich nicht erschließen, oder?
> print(f"{n} is {['not ', ''][isPrime]}a prime number")
2
>
>> Ok, Die letzte Zeile habe ich, um den Whitespace-Einrückungsgegnern> entgegenzukommen, vielleicht etwas arg geschrumpft ;-)
Der Erste, den ich sehe, der f-Strings benutzt... Bin gespannt, wann
sich der Erste darüber beschwert, der das Feature nicht kennt und es
darum doof findet. ;-)
Nick M. schrieb:> Ich empfinde das etwas seltsam, aus einer for-Schleife mit gegebenen> Grenzen mit einem Break rauszugehen.
Jaaaa... nein, nicht wirklich. In dem gezeigten Beispiel mag das
zutreffen, aber... dieses Python kann ja Schleifen über alles machen,
was ein sogenanntes Iterable ist. Das kann eine Generatorfunktion sein,
eine Liste, ein Tupel, ein String, ein Dict (auch als Hash oder
assoziatives Array bekannt), oder irgend etwas anderes, und im
Zweifelsfall auch eine eigene Klasse, die das Iterator-Interface
implementiert. In verschiedenen dieser Fälle kann es durchaus sinnvoll
sein, etwas nur dann zu machen, wenn eine solche Schleife NICHT mit
einem Break abgebrochen wurde.
Klaus H. schrieb:> Man muss List Comprehension ja nicht benutzen, wenn man nicht mag.
Comprehensions habe ich oft und gerne benutzt, bis ich feststellen
mußte, daß meine Mitarbeiter und Kollegen ihre Probleme damit haben.
Die leidigen Kollegen...
Ich habe es inzwischen aufgegeben C Programmierern die sinnvollen
Ergänzungen von C++ näher zu bringen...
Irgendwann sterben sie einfach aus...
Dummerweise ich mit ihnen... 8-0
Yalu X. schrieb:> Ich persönlich finde das for-break-else äußerst> praktisch, um nach einer Suche mit for und break> bei negativem Ausgang eine andere Folgeaktion als> bei positivem Ausgang auszuführen.
Aber der Gedanke, dass eine for-Schleife, die für
eine a priori BEKANNTE Anzahl Iterationen gedacht ist,
nicht für die Suche nach der UNBEKANNTEN Position
eines Elementes geeignet sein könnte, ist Dir noch
nicht gekommen?
Das ganze Gemurxe löst sich nämlich in Luft auf, wenn
man im gegebenen Beispiel zuerst mit einer passenden
Schleife nach dem kleinsten Teiler k (k>1) der Zahl n
sucht und danach unterscheidet ob n<k oder n=k gilt.
Also ungefähr so:
1
2
set n 407
3
4
set k 2
5
while { ($k<$n) && ([expr $n % $k]!=0) } { incr k }
Sheeva P. schrieb:> dieses Python kann ja Schleifen über alles machen,> was ein sogenanntes Iterable ist. Das kann eine Generatorfunktion sein,> eine Liste, ein Tupel, ein String, ein Dict (auch als Hash oder> assoziatives Array bekannt), oder irgend etwas anderes,
Schleife ist Schleife. Egal worüber sie iteriert. Ist auch kein
Alleinstellungsmerkmal von Python. Also auch kein Argument für das alles
andere als sprechende else das nur einen der 3 Fälle behandelt.
Nick M. schrieb:> Sheeva P. schrieb:>> dieses Python kann ja Schleifen über alles machen,>> was ein sogenanntes Iterable ist. Das kann eine Generatorfunktion sein,>> eine Liste, ein Tupel, ein String, ein Dict (auch als Hash oder>> assoziatives Array bekannt), oder irgend etwas anderes,>> Schleife ist Schleife. Egal worüber sie iteriert.
Aber es gibt dabei nur zwei Möglichkeiten. Entweder iteriert man über
alle Elemente der Sequenz, oder man verlässt die Schleife per break.
enn man z.B. ein Element in der Sequenz sucht, ist diese ja nicht
automatisch zu Ende, nur weil man das Element gefunden hat. Man muss
dann mit break rausgehen oder unnötigerweise bis zum Ende weiter
iterieren und sich in einem zusätzlichen Flag merken, ob das Element
gefunden wurde.
> Ist auch kein Alleinstellungsmerkmal von Python.
Ja. In C++ wäre es bei range-based for genauso.
Rolf M. schrieb:> Aber es gibt dabei nur zwei Möglichkeiten. Entweder iteriert man über> alle Elemente der Sequenz, oder man verlässt die Schleife per break.
So ist das nun mal beim Suchen. Wenn die Liste geordnet ist, brauch ich
dazu weder ein for (;;) noch sonst so ein Konstrukt. Da nehme ich dann
doch lieber bfind her.
Wenn sie nicht geordnet ist, dann weiß ich nicht, was du damit sagen
wolltest.
Nick M. schrieb:> Wenn sie nicht geordnet ist, dann weiß ich nicht, was du damit sagen> wolltest.
Ich wollte damit sagen, dass es nicht immer sinnvoll ist, über die
komplette Sequenz zu iterieren, sondern man manchmal vorher abbrechen
will. Und genau für diesen Fall ist dieser Konstrukt da.
Rolf M. schrieb:> Ich wollte damit sagen, dass es nicht immer sinnvoll ist, über die> komplette Sequenz zu iterieren, sondern man manchmal vorher abbrechen> will. Und genau für diesen Fall ist dieser Konstrukt da.
Nein, um eine Schleife vorzeitig zu verlassen, ist "break" da. Das
"else" hat damit nichts zu tun.
Die Schwäche von for-break-else ist, dass es ein spezielles
Sprachfeature für einen engen Anwendungsbereich ist und schlechten Code
fördert.
Auch der Python-Erfinder findet es fragwürdig:
https://mail.python.org/pipermail/python-ideas/2009-October/006157.html
Irgendwer schrieb:> Auch der Python-Erfinder findet es fragwürdig:>> https://mail.python.org/pipermail/python-ideas/2009-October/006157.html
Ich zitier hier die beiden zugehörigen Beiträge:
-------------------------------------------------
> We're talking about a single construct that the BDFL> has deigned to deprecate as an unfortunate choice of keywords.
Wrong. I would not have the feature at all if I had to do it over. I
would not choose another keyword. But I don't see the same level of
danger in it that some here see.
I am also against adding a syntax warning for this. It belongs in pylint
etc.
-------------------------------------------------
Beide Einstellungen sind verständlich.
1.) schlechtes Keyword 'else'
2.) den else-Zweig komplett weglassen.
Thread beobachten
Seitenaufteilung abschalten