Das deutsche Python-Forum

lunar hat geschrieben:Das wäre nicht der erste Fall eines schlechten Python Buchs. Viele Bücher scheinen von fachfremden Autoren geschrieben zu sein, die einfach blind aus anderen Sprachen bekannte Paradigmen auf Python zu übertragen, ohne sich vorher detailliert mit den Konzepten von Python beschäftigt zu haben.

Im Falle Lutz & Ascher sollte das eigentlich nicht sein. Ascher war bis vor kurzem im PSF-Vorstand bis er Leiter von Mozilla Messaging wurde. Daher verwundert so etwas um so mehr.

Aber Lutz schreibt da in sein Buch noch weitere so "tolle" Sachen, etwa dass man Fenster mit ``raw_input()`` offen lassen sollte.

lunar hat geschrieben:

pütone hat geschrieben:Das Hauptaugenmerk lag/liegt darauf, bei versehentlich falsch notierten Attributen eine Fehlermeldung zu bekommen, um die ansonsten in solchen Fällen manchmal schwer aufzufindenden Fehler leichter ausmachen zu können.

Dafür gibt es pylint, pychecker und Unit Tests.

Es gibt aber Nutzergruppen, für die so etwas nicht in Frage kommt, wie z.B. 14jährige, die mit Python die Grundlagen des Programmierens erlernen (wollen/sollen) ...

Warum kommt das für die nicht in Frage? Einige IDEs haben `pylint` und/oder `pychecker` integriert und lassen mindestens beim speichern über den Quelltext laufen, und das von Hand mal ab und zu auf zu rufen ist nun auch nicht so kompliziert.

Ich denke gerade `pylint` kann sehr gut dabei helfen guten Quelltext zu schreiben, weil auch einiges an Konventionen überprüft wird. Andererseits kann man es ziemlich weitgehend konfigurieren, falls man zum Beispiel bestimmte Meldungen nicht haben möchte, oder andere Richtlinien/Konventionen hat, was Anzahlen von Zeilen/Funktionen/Attributen usw. und Namenskonventionen angeht.

Und auch Unit Tests sollte man Anfängern näher bringen können. IMHO sollte man das auch unbedingt tun. Ich bin das sowohl aus der Schule als auch vom Studium gewohnt, dass man einen kleinen Test schreibt, der überprüft, ob das Programm auch wirklich dass tut, was es soll. In Python muss man ja nicht auf so ein "monströses" xUnit-ähnliches Rahmenwerk zurück greifen, wie in Java oder C++. Es gibt ja auch Doctests und zum Beispiel `py.test`, das eine recht geringe Hürde an "Formalien" stellt.