Anmerkungen zur Leseprobe:
S.14 „[…] also alle Dateitypen […]“ → Datentypen
``assert`` ist keine finale Lösung um Nutzereingaben zu kontrollieren ist eine Untertreibung: ``assert`` wird *gar nicht* verwendet um Nutzereingaben zu kontrollieren. Das ist nicht die Aufgabe. Damit testet man ob der Programmierer etwas falsch gemacht hat, also der Code die Zusicherungen, die der Programmierer gemacht hat, (nicht) erfüllt. Mit ``assert`` testet man Dinge die *immer* wahr sind. Da man weiss das der Benutzer auch gerne mal E-Mail-Adressen ohne @ eingibt, ist das nichts was immer wahr ist.
„Ob man nun zum Einrücken Leerzeichen oder Tabulatoren nutzt, ist unerheblich,“
Nope, ist es nicht: Vier Leerzeichen pro Ebene, keine Tabulatoren.
Und auch der Stil bei Namen ist nicht frei wählbar: Namen werden klein_mit_unterstrichen geschrieben. Ausgenommen Konstanten (KOMPLETT_GROSS) und Klassen (MixedCase).
Was mit Korinthen: Die Aussage das ein Bool-Wert keine Zahl ist, stimmt technisch nicht:
Code: Alles auswählen
In [214]: issubclass(bool, int)
Out[214]: True
In [215]: isinstance(True, int)
Out[215]: True
In [216]: True * 42
Out[216]: 42
In [217]: False * 23
Out[217]: 0
In [218]: True + 1
Out[218]: 2
In [219]: False - 1
Out[219]: -1
In [220]: int(True)
Out[220]: 1
In [221]: int(False)
Out[221]: 0
„Für kürzere Kommentare in einer Zeile wird das Rautenzeichen verwendet (#).“
Für *alle* Kommentare wird das Rautenzeichen verwendet. Zeichenkettenliterale sind keine Kommentare! Die sind an bestimmten Stellen für Docstrings da, deren Inhalt sich aber von Kommentaren zum Code unterscheiden, weil Kommentare den konkreten Code erklären, Dokumentation in der Regel aber nur die Funktionalität, ohne auf die konkrete Implementierung einzugehen.
Zudem sind literale Strings bei einigen Werkzeugen auch Docstrings an Stellen, die vom Python-Compiler nicht vorgesehen sind. Also kann man in der Praxis auch nicht einfach sagen „Hier gehört kein Doctsring hin, also kann man da auch eine Zeichenkette zum kommentieren verwenden“, weil dieser Kommentar dann am Ende vielleicht doch ungewollt in der Dokumentation landet.
Da PEP8 anscheinend bekannt ist, Frage ich mich warum die Empfehlungen davon teilweise so stark abweichen. Die meisten IDEs und Editoren + Plugins zum Python programmieren prüfen das ja auch mittlerweile und markieren Abweichungen entsprechend.
Das man Module ohne Seiteneffekte importieren können sollte, hätte ich ja auch für sehr praxisrelevant gehalten, weil es dann einfacher ist Code interaktiv zu testen, und so einige Bibliotheken und Werkzeuge für parallele Ausführung, Dokumentation, und automatisierte Tests das erwarten. Das „3_parallelisierung.py”-Modul wird so unter Windows beispielsweise nicht funktionieren.