Forum: PC-Programmierung Frage zu Python if else Einrückung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gerhard (Gast)


Lesenswert?

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?!
1
# Program to check if a number is prime or not
2
num = 407
3
4
# prime numbers are greater than 1
5
if num > 1:
6
   # check for factors
7
   for i in range(2,num):
8
       if (num % i) == 0:
9
           print(num,"is not a prime number")
10
           print(i,"times",num//i,"is",num)
11
           break
12
   else:
13
       print(num,"is a prime number")
14
       
15
# if input number is less than
16
# or equal to 1, it is not prime
17
else:
18
   print(num,"is not a prime number")

von Gerhard (Gast)


Lesenswert?

Zu schnell gepostet, Frage hat sich erledigt. Habe gefunden, dass in 
Python else auch auf eine for loop folgen kann.

Sorry for the noise

von Hans Müller (Gast)


Lesenswert?

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.

von Sinn dahinter? (Gast)


Lesenswert?

Hans Müller schrieb:
> es lohnt sich.

Was bringt dieses feature genau?

von Sinn dahinter? (Gast)


Lesenswert?

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....

von sid (Gast)


Lesenswert?

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

Beitrag #6494226 wurde von einem Moderator gelöscht.
von Rolf M. (rmagnus)


Lesenswert?

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.

von Ben S. (bensch123)


Lesenswert?

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
}

Erschließt sich mir nicht.

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Lesenswert?

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.

: Bearbeitet durch User
von Gerhard (Gast)


Lesenswert?

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 ...

von Ben S. (bensch123)


Lesenswert?

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.

von Nick M. (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Nick M. (Gast)


Lesenswert?

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
int upper = 10;
2
int iter = 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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
         goto mybreak; // 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 ;-)

: Bearbeitet durch Moderator
von afran (Gast)


Lesenswert?

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:
1
for el in [1, 2, 3]:
2
  if el ...
3
    # Gefunden
4
    break
5
else:
6
  # Nicht gefunden
7
  ...

Beitrag #6494440 wurde von einem Moderator gelöscht.
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

: Bearbeitet durch Moderator
von Rolf M. (rmagnus)


Lesenswert?

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.

von Simi S. (kokoianer)


Angehängte Dateien:

Lesenswert?

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.

von Nick M. (Gast)


Lesenswert?

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
const int upper = 10;
2
int iter = 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.

von Nick M. (Gast)


Lesenswert?

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. :-)

von Le X. (lex_91)


Lesenswert?

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.

: Bearbeitet durch User
von Nick M. (Gast)


Lesenswert?

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. ;-)

von Le X. (lex_91)


Lesenswert?

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 ;-)

: Bearbeitet durch User
von absurd (Gast)


Lesenswert?

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.

von Nick M. (Gast)


Lesenswert?

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.

von Nick M. (Gast)


Lesenswert?

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.

von Nick M. (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

: Bearbeitet durch User
von Klaus H. (klummel69)


Lesenswert?

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?

: Bearbeitet durch User
von Nick M. (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

: Bearbeitet durch Moderator
von Nick M. (Gast)


Lesenswert?

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.html
https://ioccc.org/

von afran (Gast)


Lesenswert?

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.

von Klaus H. (klummel69)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Nick M. (Gast)


Lesenswert?

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.

von warumNurImmer (Gast)


Lesenswert?

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?

von warumNurImmer (Gast)


Lesenswert?

Nick M. schrieb:
> Ich kenn ja kein Python, daher schaut das wohl für mich verwirrend
> aus.

ohh man... jetzt kennst du es nicht? =D

von Nick M. (Gast)


Lesenswert?

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.

Beitrag #6494653 wurde von einem Moderator gelöscht.
von Andreas (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

: Bearbeitet durch Moderator
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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?

von Sheeva P. (sheevaplug)


Lesenswert?

Yalu X. schrieb:
>
1
> 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. ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Le X. schrieb:
> Vielleicht hätte Guido anstelle von Einrückungen Kommentare erzwingen
> sollen ;-)

Ich möchte nicht wissen, wie viele
1
def irgendwas():
2
    '''foo'''
3
    pass

wir dann sehen würden... ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

absurd schrieb:
> Oder gibt es jetzt auch while-break-Schleife?

Nein, dann heißt es natürlich while...else.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von absurd (Gast)


Lesenswert?

ah, ich verstehe. Und do-while ist dann do-while-else-Schleife

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

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Klaus (Gast)


Lesenswert?

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

von Egon D. (egon_d)


Lesenswert?

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 } 
6
7
if {$k==$n} then { 
8
  puts "$n ist Primzahl." 
9
} else { 
10
  puts "$n ist keine Primzahl." 
11
}

: Bearbeitet durch User
von Nick M. (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Nick M. (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Irgendwer (Gast)


Lesenswert?

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

von Nick M. (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.