Hallo zusammen,
ich möchte gerne Python 2 Figuren nacheinander zeichnen lassen.
Für die erste Figur wählt der User Farben aus einer Liste aus. Die Figur wird dann gezeichnet.
Dann soll der User die Info erhalten, dass jetzt die Figur nochmal mit den "NICHT GEWÄHLTEN" Farben gezeichnet wird.
Am Ende soll ein Text ausgegeben werden.
Mein Coding mit meinen Überlegungen:
# Bereitstellung der library TURTLE mit Funktionen und Methoden, die man in diesem Programm nutzen kann
import turtle
import time
# erstmal definieren wir eine Variable namens "colors" vom Typ LISTE, mit den Farben, die vorkommen dürfen.
# Listen werden durch eckige Klammern definiert
colors = ["red","green","blue","orange","purple","yellow"]
# wir definieren eine weitere Variable names user_colors vom Typ LISTE (zu erkennen an den eckigen Klammern)
user_colors = []
# Liste für den 2. Durchlauf
user2_colors = []
# So lange die zuvor genannte Variable "user_colors" weiterhin leer ist, soll diese Schleife immer wieder durchlaufen werden
while True:
# es werden dem Anwender nochmal alle Farben angezeigt
print("Verfügbare Farben sind: ", colors)
# der Anwender soll nun eine Farbe eingeben, die damit in die Variable "color_choice" geschrieben wird
color_choice = input("Geben Sie eine der verfügbaren Farben ein: ")
# jetzt muss die Eingabe geprüft werden
# 1. Fall: der Anwender hat eine Farbe eingetragen, die in der Liste "colors" enthalten ist
if color_choice in colors:
user_colors.append(color_choice) # Farbe in die Variable "user_colors" schreiben
colors.remove(color_choice) # die gewählte Farbe darf kein 2. Mal gewählt werden
print(color_choice, " hinzugefügt")
# 2. Fall: Anwender hat nichts eingetragen und ENTER gedrückt, Damit wird die WHILE-Schleife verlassen
elif color_choice =="":
break
# 3. Fall: Der Anwender hat eine Farbe gewählt, die nicht (mehr) verfügbar ist
else:
print("Diese Farbe ist nicht verfügbar !")
# Hier sollen alle nicht gewählten Farben aus der Ausgangsliste in einer Liste gesammelt werden
user2_colors.append(colors)
# Fenster einrichten (s ist eine beliebige Variable, da könnte auch e oder wurst stehen)
# Befehl öffnet ein Fenster 800 x 800 Pixel mit Überschrift FARBWECHSELNDE FIGUR
s = turtle.Screen()
s.setup(width=800, height=800)
s.title("Farbwechselnde Figur")
s.bgcolor('black')
# Schildkröte einrichten (w ist eine beliebige Variable, da könnte auch e oder wurst stehen)
w = turtle.Turtle()
w.pensize(3)
# Geschwindigkeit geht von 0 = langsam bis 10 = schnell
w.speed(200)
# 1. Figur zeichnen (300 ist die Anzahl der Striche, die gemacht werden)
for i in range(100): #
color_choice = user_colors[i % len(user_colors)]
w.color(color_choice)
w.forward(i)
w.left(50)
time.sleep(3)
write("Jetzt malen wir die Figur mit den nicht gewählten Farben", align="left")
# Jetzt soll die Figur in den Farben gezeichnet werden, die nicht gewählt wurden
for i in range(100): #
color_choice = user2_colors[i % len(user2_colors)]
w.color(color_choice)
w.forward(i)
w.left(50)
time.sleep(3)
write("Dies war das Programm von X und Y", align="left")
# Fenster offen halten
s.mainloop()
Wo ist denn mein Fehler ?
leider werden die Texte nicht angezeigt und die 2. Figur wird nicht gezeichnet....
2 Figuren nacheinander zeichnen
Hallo,
'write' ist nicht definiert, du solltest dafür eine Fehlermeldung bekommen, wenn die erste Figur gezeichnet wurde.
Kommt die bei dir nicht?
Grüße
Dennis
'write' ist nicht definiert, du solltest dafür eine Fehlermeldung bekommen, wenn die erste Figur gezeichnet wurde.
Kommt die bei dir nicht?
Grüße
Dennis
"When I got the music, I got a place to go" [Rancid, 1993]
- __blackjack__
- User
- Beiträge: 14057
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@mandy_1993: Anmerkungen zum Quelltext:
Kommentare sollen dem Leser einen Mehrwert über den Code geben. Faustregel: Kommentare beschreiben nicht *was* der Code macht, denn das steht da bereits als Code, sondern warum er das macht. Sofern das nicht offensichtlich ist. Offensichtlich ist in aller Regel auch was in der Dokumentation von Python und den verwendeten Bibliotheken steht.
Falsche Kommentare sind schlimmer als keine Kommentare. Ein Kommentar sollen eventuelle Fragen mit dem Code klären, aber wenn dort falsche Informationen drin stehen, oder gar welche die dem Code direkt wiedersprechen, erreicht man genau das Gegenteil. Der Leser weiss dann nicht was falsch ist, der Code oder der Kommentar.
Der Kommentar bei der ersten ``while``-Schleife stimmt beispielsweise nicht. Die wird nicht solange durchlaufen wie die Liste leer ist. Auch bei leerer Liste kann der Benutzer einfach nichts eingeben und damit die Eingabe abbrechen. Das Programm läuft dann in einen `ZeroDivisionError` beim versuch die Schleifenlaufvariable `i` durch die Länge der Liste zu teilen um den Rest zu bestimmen (``%``-Operator).
Das umgekehrte Problem wird man bekommen falls der Benutzer tatsächlich *alle* Farben wählt, dann gibt es keine Farbe(n) mehr für die zweite Figur! Das bedeutet auch, das mindestens zwei Farben zur Auswahl stehen müssen.
Wenn im Kommentar steht die Geschwindigkeit kann Werte von 0 bis 10 annehmen, im Code dann aber 200 gesetzt wird, oder im Kommentar steht die 300 steht für die Anzahl der Striche, im Code dann aber überhaupt gar keine 300 steht, ist das verwirrend, und die Kommentare erreichen das Gegenteil vom Grund warum man Kommentare schreibt: Fragen vom Leser beantworten, die durch den Code entstehen.
Kommentare werden genau wie der Code eingerückt, sonst macht man sich damit die ansonsten sichtbare Code-Struktur kaputt, was ja der Grund (für Menschen) ist, überhaupt einzurücken.
Man definiert Namen nicht irgendwo am Anfang “auf Vorrat”, sondern dann, wenn man sie braucht. `user2_colors` wird an der Stelle wo es definiert wird, noch gar nicht gebraucht.
Die Liste mit den nicht gewählten Farben an `user2_colors` anzuhängen ist etwas anderes als jede der nicht gewählten Farben anzuhängen. Aber das ist sowieso überflüssig, denn am ende wäre `user2_colors` bloss eine Kopie von `colors` — warum dann nicht einfach `colors` verwenden‽ Namen nummerieren ist sowieso keine gute Idee.
„s ist eine beliebige Variable, da könnte auch e oder wurst stehen“ stimmt so überhaupt gar nicht. Namen sollen dem Leser vermitteln was der Wert im Programm bedeutet. Das tun Einbuchstabige Namen *sehr* selten, und ”irgendwelche” Namen wie `wurst` schon gar nicht. Bei `s` für `screen` kann man ja noch einen Bezug sehen, aber warum `w` für die Schildkröte wird kaum ein Leser verstehen. Aber die meisten rätseln da dann trotzdem und `w` steht in GUI-Programmen dann oft für „window“ oder „widget“, was beides nicht stimmt, man muss dann beim Lesen also immer gegen diese falsche Vermutung ankämpfen. Das führt dann gerne mal zu Fehlern.
Der Code für das Zeichnen der Figur wurde kopiert, eingefügt, und leicht angepasst. Das macht man nicht. Dafür gibt es Funktionen. Dann muss man den Code nur einmal schreiben, und es besteht nicht die Gefahr, dass man Fehler beim schreiben oder späteren anpassen macht, weil man da dann darauf aufpassen müsste alle Kopien zu verändern und das auch jedes mal gleichwertig zu machen.
Zwischenstand:
Kommentare sollen dem Leser einen Mehrwert über den Code geben. Faustregel: Kommentare beschreiben nicht *was* der Code macht, denn das steht da bereits als Code, sondern warum er das macht. Sofern das nicht offensichtlich ist. Offensichtlich ist in aller Regel auch was in der Dokumentation von Python und den verwendeten Bibliotheken steht.
Falsche Kommentare sind schlimmer als keine Kommentare. Ein Kommentar sollen eventuelle Fragen mit dem Code klären, aber wenn dort falsche Informationen drin stehen, oder gar welche die dem Code direkt wiedersprechen, erreicht man genau das Gegenteil. Der Leser weiss dann nicht was falsch ist, der Code oder der Kommentar.
Der Kommentar bei der ersten ``while``-Schleife stimmt beispielsweise nicht. Die wird nicht solange durchlaufen wie die Liste leer ist. Auch bei leerer Liste kann der Benutzer einfach nichts eingeben und damit die Eingabe abbrechen. Das Programm läuft dann in einen `ZeroDivisionError` beim versuch die Schleifenlaufvariable `i` durch die Länge der Liste zu teilen um den Rest zu bestimmen (``%``-Operator).
Das umgekehrte Problem wird man bekommen falls der Benutzer tatsächlich *alle* Farben wählt, dann gibt es keine Farbe(n) mehr für die zweite Figur! Das bedeutet auch, das mindestens zwei Farben zur Auswahl stehen müssen.
Wenn im Kommentar steht die Geschwindigkeit kann Werte von 0 bis 10 annehmen, im Code dann aber 200 gesetzt wird, oder im Kommentar steht die 300 steht für die Anzahl der Striche, im Code dann aber überhaupt gar keine 300 steht, ist das verwirrend, und die Kommentare erreichen das Gegenteil vom Grund warum man Kommentare schreibt: Fragen vom Leser beantworten, die durch den Code entstehen.
Kommentare werden genau wie der Code eingerückt, sonst macht man sich damit die ansonsten sichtbare Code-Struktur kaputt, was ja der Grund (für Menschen) ist, überhaupt einzurücken.
Man definiert Namen nicht irgendwo am Anfang “auf Vorrat”, sondern dann, wenn man sie braucht. `user2_colors` wird an der Stelle wo es definiert wird, noch gar nicht gebraucht.
Die Liste mit den nicht gewählten Farben an `user2_colors` anzuhängen ist etwas anderes als jede der nicht gewählten Farben anzuhängen. Aber das ist sowieso überflüssig, denn am ende wäre `user2_colors` bloss eine Kopie von `colors` — warum dann nicht einfach `colors` verwenden‽ Namen nummerieren ist sowieso keine gute Idee.
„s ist eine beliebige Variable, da könnte auch e oder wurst stehen“ stimmt so überhaupt gar nicht. Namen sollen dem Leser vermitteln was der Wert im Programm bedeutet. Das tun Einbuchstabige Namen *sehr* selten, und ”irgendwelche” Namen wie `wurst` schon gar nicht. Bei `s` für `screen` kann man ja noch einen Bezug sehen, aber warum `w` für die Schildkröte wird kaum ein Leser verstehen. Aber die meisten rätseln da dann trotzdem und `w` steht in GUI-Programmen dann oft für „window“ oder „widget“, was beides nicht stimmt, man muss dann beim Lesen also immer gegen diese falsche Vermutung ankämpfen. Das führt dann gerne mal zu Fehlern.
Der Code für das Zeichnen der Figur wurde kopiert, eingefügt, und leicht angepasst. Das macht man nicht. Dafür gibt es Funktionen. Dann muss man den Code nur einmal schreiben, und es besteht nicht die Gefahr, dass man Fehler beim schreiben oder späteren anpassen macht, weil man da dann darauf aufpassen müsste alle Kopien zu verändern und das auch jedes mal gleichwertig zu machen.
Zwischenstand:
Code: Alles auswählen
#!/usr/bin/env python3
import time
from turtle import Screen, Turtle
SCREEN_SIZE = 800
def draw_figure(turtle, colors):
for i in range(100):
turtle.color(colors[i % len(colors)])
turtle.forward(i)
turtle.left(50)
def main():
colors = ["red", "green", "blue", "orange", "purple", "yellow"]
user_colors = []
assert len(colors) >= 2
#
# Es muss mindestens eine Farbe für die 2. Figur übrig bleiben.
#
while len(colors) > 1:
print("Verfügbare Farben sind: ", colors)
color_choice = input(
"Geben Sie eine der verfügbaren Farben ein: "
).strip()
if color_choice in colors:
user_colors.append(color_choice)
colors.remove(color_choice)
print(color_choice, "hinzugefügt")
elif color_choice == "":
if user_colors:
break
print("Bitte mindestens eine Farbe auswählen!")
else:
print("Diese Farbe ist nicht verfügbar!")
screen = Screen()
screen.setup(width=SCREEN_SIZE, height=SCREEN_SIZE)
screen.title("Farbwechselnde Figur")
screen.bgcolor("black")
turtle = Turtle()
turtle.pensize(3)
turtle.speed(200)
draw_figure(turtle, user_colors)
time.sleep(3)
turtle.write(
"Jetzt malen wir die Figur mit den nicht gewählten Farben",
align="left",
)
draw_figure(turtle, colors)
time.sleep(3)
turtle.write("Dies war das Programm von X und Y", align="left")
screen.mainloop()
if __name__ == "__main__":
main()
“Vir, intelligence has nothing to do with politics!” — Londo Mollari