Da muss ich immer hieran denken: Linksnafu hat geschrieben: Nee, hab ich nicht.
Tutorial: Einfache Textmenüs mit Python
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Das Ding ist gut. Richtig gut.Hyperion hat geschrieben:Es sind sicherlich noch einige Fehler darin enthalten, daher würde ich mich über "Debug"-Hilfe freuen
Nur gegenüber
Code: Alles auswählen
if choice in range(len(menu)):
Code: Alles auswählen
if 0 <= choice < len(menu):
*edit* Ich hatte vorher einen Fehler gesehen wo keiner war.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
@me: Danke. Ich habe die Überprüfung auf Deinen Vorschlag umgestellt.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Meiner Meinung nach kommt die Warnung einen Absatz zu spät. Ich finde, gerade wegen der Häufigkeit des Antreffens, sollte man das direkt als erstes unter den Code-Kasten schreiben. Oder als Kommentar über die Schleife?Hyperion hat geschrieben:Danke für die Kritik
@frabron: Wie würdest Du denn begründen, dass man diesen Anti-Pattern nicht verwenden sollte? Ich dachte die nachfolgende Darstellung würde ausreichen. Aber vielleicht muss da tatsächlich mehr "Kausalität" rein.
Code: Alles auswählen
# Bitte so nicht machen, denn das ist ein typischer Anfängerfehler. Wieso steht weiter unten
So kann man auch als Laie das Anti-Pattern erkennen, da es nun konkret benannt ist durch Nennung von `range()` und `len()`.Leider ist obiger Code schlecht! Er ist eines der berühmten Anti-Pattern, die man häufig bei Anfängern oder Umsteigern von anderen Sprachen sieht. Durch den Aufruf zweier, in diesem Zusammenhang, unnötiger Funktionen (range() und len()) wirkt der Code unleserlicher, ausserdem ist er unnötig kompliziert.
Frank
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Ich habe Deine Ideen zum Teil übernommen. Die Warnung im Code mag ich nicht einführen, da der Leser zum einen sonst frühzeitig abgelenkt wird und zum anderen demotiviert wird, das ganze zu durchdenken. Er soll ja genau darauf hingeführt werden, wie viel einfacher und leserlicher die Lösung mittels `enumerate` ist. Genauso so habe ich es ja auch mit der "schlechten" Lösung des Gesamtproblems gehandhabt: Erst einmal vorstellen und dann erklären, wieso man das nicht so machen sollte und die sinnvolle Lösung aufzeigen. Ich denke, dass ich so der Stil des Tutorials und den mag ich nicht brechen. Wer die Warnung dann überliest, der wird das Tutorial eh nicht richtig durcharbeiten und somit nichts lernen
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Ja, so kann man es machen, da stimme ich dir zu. Gerade der Teil mit der Konsistenz kann imo nicht überbewertet werden. Man könnte solche Hinweise natürlich noch etwas stärker hervorheben. Keine Ahnung, ob Markdown da etwas anbietet. Inspiriert haben mich da ein paar Lehrbücher, da gibt es ja auch öfter mal so Kästchen und Zeigefinger-Grafiken.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Ja, solche Hervorhebungen wären schon nett. Genauso stört es mich, dass das Syntaxhighlighting für die Konsolensessions nicht gut funzt.
Also an alle Github-Erfahrenen: Gibt es da ein spezielles Highlighting? Und gibt es solche Hervorhebungen?
Also an alle Github-Erfahrenen: Gibt es da ein spezielles Highlighting? Und gibt es solche Hervorhebungen?
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Dafür gibt es das „pycon“-Syntax-Highlighting, das aber nur für „normale“ Python-Sitzungen funktioniert.Hyperion hat geschrieben:Genauso stört es mich, dass das Syntaxhighlighting für die Konsolensessions nicht gut funzt.
***Das ist die stärkste Hervorhebung.***Hyperion hat geschrieben:Und gibt es solche Hervorhebungen?
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Also nicht für IPython? Ich werds mal testen, vielleicht ist das ja doch akzeptabelnomnom hat geschrieben:Dafür gibt es das „pycon“-Syntax-Highlighting, das aber nur für „normale“ Python-Sitzungen funktioniert.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Tolles Tutorial. Guter Schreibstil. Da muss ich im Vergleich mein Tutorial noch zurückhalten und überarbeiten
Ich schlage ebenfalls vor, auf IPython zu verzichten. Das verwirrt mehr, als es hilft, auch wenn es praktisch scheint, um auf Ausdrücke zu verweisen. Zudem finde ich's doof, dass Pygments das "ü" und "ö" als Fehler hervorhebt oder andere komische Dinge mit der Ausgabe macht.
Ich würde auch auf "sys.exit()" verzichten und einfach "break" benutzen. Das macht in den ersten Beispielen die Funktion "menu" wiederverwendbar.
Wenn du format() nicht zum Formatieren benutzt, würde statt
auch einfach
funktionieren. Und da ich eher ein Fan von "%" bin, würde ich wenn schon, dann
benutzen, damit auch Zahlen > 9 noch schön untereinander ausgerichtet werden.
Übrigens, man darf in einem Tutorial ruhig lügen, wenn es dem Verständnis dient. Die Aussage "alles ist ein Objekt" kann man IMHO so stehen lassen. Ich würde wahrscheinlich von Werten sprechen, nicht Objekten, um sie klar von Exemplaren abzugrenzen. Letztlich ist aber in Python AFAIK auch alles ein Exemplar einer Klasse, selbst Klassen. Etwas wie "ich kann jeden Wert in ein dict stecken" würde dann aber auch gehen. Der Exkurs "Funktionen sind auch Objekte" ist IMHO ein bisschen zu lang. Ehrlich gesagt würde ich Objekte komplett raus lassen und nur argumentieren, dass Funktionen Werte sind, und damit überall dort benutzt werden können, wo man andere Werte wie Zahlen oder Zeichenketten benutzen kann (sie sind "first class").
Bei
kannst du übrigens die Macht von Unicode spielen lassen
Als Tipp, wie es weitergehen könnte: Annotiere Funktionen mit `@menu(x)`, um sie auf diese Weise in ein Menü `x` einzufügen. Sie werden in der Reihenfolge eingefügt, wie sie im Quelltext stehen. Der letzte Punkt ist immer "Ende" bzw. "Zurück", wenn es sich um ein Untermenü handelt.
Stefan
Ich schlage ebenfalls vor, auf IPython zu verzichten. Das verwirrt mehr, als es hilft, auch wenn es praktisch scheint, um auf Ausdrücke zu verweisen. Zudem finde ich's doof, dass Pygments das "ü" und "ö" als Fehler hervorhebt oder andere komische Dinge mit der Ausgabe macht.
Ich würde auch auf "sys.exit()" verzichten und einfach "break" benutzen. Das macht in den ersten Beispielen die Funktion "menu" wiederverwendbar.
Wenn du format() nicht zum Formatieren benutzt, würde statt
Code: Alles auswählen
print("{} {}".format(index+1, menu[index]))
Code: Alles auswählen
print(index+1, menu[index])
Code: Alles auswählen
print("%2d .. %s" % (index + 1, menu[index]))
Übrigens, man darf in einem Tutorial ruhig lügen, wenn es dem Verständnis dient. Die Aussage "alles ist ein Objekt" kann man IMHO so stehen lassen. Ich würde wahrscheinlich von Werten sprechen, nicht Objekten, um sie klar von Exemplaren abzugrenzen. Letztlich ist aber in Python AFAIK auch alles ein Exemplar einer Klasse, selbst Klassen. Etwas wie "ich kann jeden Wert in ein dict stecken" würde dann aber auch gehen. Der Exkurs "Funktionen sind auch Objekte" ist IMHO ein bisschen zu lang. Ehrlich gesagt würde ich Objekte komplett raus lassen und nur argumentieren, dass Funktionen Werte sind, und damit überall dort benutzt werden können, wo man andere Werte wie Zahlen oder Zeichenketten benutzen kann (sie sind "first class").
Bei
Code: Alles auswählen
x >= 0 /\ x < 10
Code: Alles auswählen
x ≥ 0 ∧ x < 10
Stefan
@sma: Ich mag ``%`` ja auch lieber, aber Zahlen auf x Stellen zu formatieren geht auch mit `format()`:
Code: Alles auswählen
In [206]: '{0:2d}'.format(1)
Out[206]: ' 1'
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
Der under_score_ hat in Python keine besondere Bedeutung, sondern ist ein ein ganz normaler Bezeichner.sh4nks hat geschrieben:Was macht das underline?
Konnte bei Google nichts finden, da ich nicht weiß was die genaue Bezeichnung ist
Fuer Programmierer hat er aber meistens zu bedeuten "Ich bekomme Werte, die ich nicht nutze, und will das kenntlich machen".
Michael Markert ❖ PEP 8 Übersetzung ❖ Tutorial Übersetzung (3.x) ⇒ Online-Version (Python 3.3) ❖ Deutscher Python-Insider ❖ Projekte
Das ist ein ganz normaler gültiger Name für einen Bezeichner. Der Code hätte stattsh4nks hat geschrieben:Was macht das underline
Code: Alles auswählen
_, command = menu
Code: Alles auswählen
name, command = menu
Und das ist genau der Knackpunkt an der Sache. Eine nicht unerhebliche Anzahl von Python-Entwicklern verwenden den Unterstrich als Bezeichner an Stellen wo ein Bezeichner gebraucht wird, der anschließend keine Rolle mehr spielt. Der Unterstrich ist absolut nichtssagend und genau das ist es, was die Bedeutung dieses Parameters dort im Code ausmacht.
Ab und zu wird der Unterstrich von manchen Entwicklern auch als Verkürzung für oft verwendete Funktionen benutzt.
Code: Alles auswählen
>>> from __future__ import print_function
>>> _ = print
>>> _('Hallo')
Hallo
Ah ok danke.
Dies würde aber so auch funktionieren:
Ist es eine schlechte Idee das so zu verwenden?
Dies würde aber so auch funktionieren:
Code: Alles auswählen
command = menu[choice][1]
Das würde auch funktionieren, nur macht es mMn. unleserlicher.
the more they change the more they stay the same
Ich finde den "_" im Gegenteil "intention revealing" und auch wenn Python das im Gegensatz zu anderen Sprachen nicht als Teil der Semantik kennt, ist es IMHO guter Stil. Ein anderes Beispiel wäre "i" für eine Schleifenvariable oder das man eine Pluralform wählt, wenn man eine Collection von Dingen bezeichnen will./me hat geschrieben:Ich mag diesen Einsatz [gemeint ist der Unterstrich] ]nicht so. Er konterkariert PEP-20 (Zen of Python) und PEP-8 bei den Punkten "Readability counts." unter besonderer Berücksichtigung von "code is read much more often than it is written"
Die Python-IDE PyCharm weiß bei ihrer heuristischen Typanalyse beispielsweise, dass sie das "_" nicht an unbenutzt Variable markieren soll. Würde man `foo, bar = foobars` schreiben und dann `foo` nie wieder benutzen, würde PyCharm das als wahrscheinlichen anmerken.
Stefan
Hier scheine ich den Kontext nicht deutlich genug gemacht zu haben. Ich mag den Unterstrich "als Verkürzung für oft verwendete Funktionen" nicht, sonst durchaus.sma hat geschrieben:Ich finde den "_" im Gegenteil "intention revealing" und auch wenn Python das im Gegensatz zu anderen Sprachen nicht als Teil der Semantik kennt, ist es IMHO guter Stil. Ein anderes Beispiel wäre "i" für eine Schleifenvariable oder das man eine Pluralform wählt, wenn man eine Collection von Dingen bezeichnen will.
Gerade habe ich noch 66,70€ für das Upgrade Subscription Renewal ausgegeben. Und das mir als FSFE-Fellow ...sma hat geschrieben:Die Python-IDE PyCharm ...
Ach so. Ja, das teile ich./me hat geschrieben:Hier scheine ich den Kontext nicht deutlich genug gemacht zu haben. Ich mag den Unterstrich "als Verkürzung für oft verwendete Funktionen" nicht, sonst durchaus.
sma hat geschrieben:Die Python-IDE PyCharm ...
Wird nicht immer gepredigt: Free != Kostenlos Gute Software darf ruhig etwas kosten, finde ich./me hat geschrieben:Gerade habe ich noch 66,70€ für das Upgrade Subscription Renewal ausgegeben. Und das mir als FSFE-Fellow ...
Außerdem: Die Grund-IDE von Jetbrains für Java, Scala und Android ist ja außerdem auch als Opensource verfügbar...
Stefan