Tutorial: Einfache Textmenüs mit Python
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
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
PyCharm ist aber weder "free" noch "kostenlos", von daher fällt dieser Vergleich flach.sma hat geschrieben: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 ...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Noch Anmerkungen von mir: Bei Code Beispielen die absichtlich "schlecht" sind, würde ich davor darauf hinweisen.
Das folgende, würde ich anders machen:
eh so:
...und ganz wichtig: überall statt input() lieber raw_input() nehmen! Und kurz erwähnen, das input() eigentlich eval(raw_input(prompt)) ist und das ist keine gute Idee.
Im Tutorial kannst du dann noch kurz auf try...except eingehen und es fehlt IMHO am Ende ein Beispiel das funktioniert. Also noch die pseudo Funktionen dabei packen. Dann kann man direkt copy&paste und probieren.
und zum Schluss, das ganze in's Wiki packen Der fertige Code kann ja bei github bleiben und verlinkt werden...
Das folgende, würde ich anders machen:
Code: Alles auswählen
def get_user_input(menu):
while True:
try:
choice = int(input("Ihre Wahl?: ")) - 1
if 0 <= choice < len(menu):
return choice
else:
raise IndexError
except (ValueError, IndexError):
print("Bitte nur Zahlen aus dem Bereich 1 - {} eingeben".format(
len(menu)))
def handle_menu(menu):
while True:
print_menu(menu)
choice = get_user_input(menu)
menu[choice][1]()
Code: Alles auswählen
def get_user_input(menu):
while True:
try:
choice = int(raw_input("Ihre Wahl?: "))
choice -= 1
return menu[choice][1]
except (ValueError, IndexError):
print("Bitte nur Zahlen aus dem Bereich 1 - {} eingeben".format(
len(menu)))
def handle_menu(menu):
while True:
print_menu(menu)
func = get_user_input(menu)
func()
Im Tutorial kannst du dann noch kurz auf try...except eingehen und es fehlt IMHO am Ende ein Beispiel das funktioniert. Also noch die pseudo Funktionen dabei packen. Dann kann man direkt copy&paste und probieren.
und zum Schluss, das ganze in's Wiki packen Der fertige Code kann ja bei github bleiben und verlinkt werden...
Oder um genau zu sein:sma hat geschrieben:Wenn du format() nicht zum Formatieren benutzt, würde statt
auch einfachCode: Alles auswählen
print("{} {}".format(index+1, menu[index]))
Code: Alles auswählen
print(index+1, menu[index])
Code: Alles auswählen
print(index + 1, menu[index], sep=' ')
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Danke für die weiteren Anmerkungen. Ich war einige Tage offline und muss das erst einmal in Ruhe durchlesen und mir überlegen, was ich wie umsetze.
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