@iNoob: Tiger-Jython basiert auf Jython und das ist immer noch bei Python 2.7. Da wird bei `input()` die Eingabe als Python-Ausdruck ausgewertet, im Kontext des Funktionsaufrufs. Also man könnte da ohne rechnen zu müssen immer die gleiche, richtige Antwort eingeben: zahl1 * zahl2
In Python 2/Tiger-Jython müsste man `raw_input()` statt `input()` verwenden.
Zum aktuellen Quelltext: ``while``-Schleifen bei denen man vorher eine Variable die in der Bedingung benötigt wird mit irgendeinem ”Dummy”-Wert belegen muss, weil der tatsächliche Wert erst *in* der Schleife zugewiesen wird, macht man nicht. Falls doch, dann sollte der Dummywert wenigstens den passenden (Duck)Typ haben. Also hier auch eine Zeichenkette sein, und keine Zahl (0). Oder `None` das mit jedem Typ ”kompatibel” ist. Da Python keine Syntax für eine nachprüfende Schleife hat, löst man das aber eigentlich idiomatisch mit einer Endlosschleife die mit ``break`` verlassen wird. Da haben wir hier allerdings das Problem, das der Punkt an dem das entschieden wird, selbst in einer inneren Schleife steht, also dort zwei verschachtelte Schleifen verlassen werden müssen. Das kann man wie schon gezeigt durch einen speziellen Wert für die Eingabe lösen, den man nach der inneren Schleife dann noch mal prüft.
Die Auswertung der Antwort nicht in der Schleife für die Eingabe zu machen, vereinfacht den Code, und ermöglicht es auch die Eingabe der Antwort in eine eigene Funktion heraus zu ziehen, wenn einem die Hauptfunktion zu unübersichtlich wird.
Das ``if eingabe != "x":`` ist unnötig, denn das ist garantiert *immer* wahr. Denn wäre `eingabe` gleich "x", dann kommt das Programm nicht zu diesem ``if``, da das ``if`` vorher die Schleife abbricht. Ausserdem wäre das auch sonst kein ``if`` mit einer genau umgekehrten Bedingung zum vorherigen ``if``, denn dafür gibt es ja ``else``.
Bei der Auswertung sind Wiederholungen die man als Programmierer vermeiden würde. Das Umwandeln in `int()` beispielsweise. Und das in beiden Zweigen am Ende ein ``break`` steht (was da sowieso nicht stehen müsste, wenn die Auswertung nicht in der inneren ``while``-Schleife stünde). Und eigentlich auch die Teilzeichenkette in der die Aufgabe + Lösung aufgebaut wird.
Wieder überarbeitet und ungetestet:
Code: Alles auswählen
#!/usr/bin/env python3
import random
def main():
punkte = 0
fehler = 0
while True:
zahl1 = random.randint(1, 9)
zahl2 = random.randint(1, 9)
loesung = zahl1 * zahl2
print(f"{zahl1} × {zahl2}")
while True:
eingabe = input("Wie lautet die Lösung? ")
if eingabe == "x":
antwort = None
break
try:
antwort = int(eingabe)
break
except ValueError:
print(
"Fehler: Bitte eine ganze Zahl eingeben, oder x um zu"
" beenden.\n"
)
if antwort is None:
break
if antwort == loesung:
ausgabe = "Die Lösung ist richtig!"
punkte += 1
else:
ausgabe = "Leider falsch!"
fehler += 1
print(
f"{ausgabe} {zahl1} × {zahl2} = {loesung}.\n"
f"OK. {punkte} Punkte und {fehler} Fehler.\n"
)
if __name__ == "__main__":
main()
Für eine GUI muss man nicht nur Funktionen schreiben können, sondern für jede nicht-triviale GUI auch Klassen. Und selbst für sehr einfache GUI-Programme muss man `functools.partial()` verstehen und anwenden. Und der Programmfluss funktioniert komplett anders als prozeduraler Code mit ``if``/``else`` und Schleifen.
