Seite 1 von 1
Best Practice? (because there is no type safety)
Verfasst: Dienstag 14. August 2012, 19:39
von MaxMx
Hallo.
ich finde Python ja seit ein paar Wochen ganz gut. Aber mir fällt ein Problem immer wieder auf:
Mit der Zeit will man ja etwas an den Strukturen verändern... zB...:
1)
... sollen bestimmte Subklassen entstehen, die einen Teil der Superklasse zusammenfassen (nicht so sehr wegen Zugriffsrechte, sondern wegen der Übersichtlichkeit)
2)
... oder es sollen Basisklassen rausgezogen werden, weil man sie für andere Ableitungen gerne hätte.
3)
.. oder Signaturen von Methoden ändern sich, weil man mehr Funktionalität braucht, oder eben anders braucht.
Ich habe festgestellt, dass ich (vor allem bei 1 und 3) ne ganze Weile beschäftig bin, bis alles wieder korrekt läuft. Bei Sprachen wie C oder C++ meckert ja meistens der Compiler, dass etwas nicht stimmt.
--Meine Frage also:
Wie gehe ich am besten bei Python vor, damit ich irgendwann nicht 90% meiner Zeit damit verbringe, bei jeder Änderung Funktionsaufrufe zu fixen?
1) konsequent unit tests schreiben - als ersatz für compiler?
2) vorher alles durchdesignen, und nie wieder verändern? (lol:)
3) IDEs, die Änderungen im ganzen Projekt propagieren?
4) ...?
Re: Best Practice? (because there is no type safety)
Verfasst: Dienstag 14. August 2012, 19:47
von BlackJack
@MaxMx: Unit-Tests.
Re: Best Practice? (because there is no type safety)
Verfasst: Dienstag 14. August 2012, 20:32
von cofi
Ebenfalls: Unittests.
Tools wie pylint, pychecker und pyflakes helfen auch.
P.S.: Type Safety heisst was anderes als du denkst (oder zumindest was der Post erahnen laesst).
Re: Best Practice? (because there is no type safety)
Verfasst: Dienstag 14. August 2012, 22:04
von snafu
Was sind denn konkret die Fehlerarten? Ausnahmen (`TypeError`, `AttributeError`, ...) oder unerwartete Ergebnisse?
Wenn man sich auf eine Sprache wie Python einlässt, dann muss man sich einfach bewusst machen, dass *Verhalten* und weniger ein bestimmter Typ erwartet wird. Das kann manchmal nervig sein - keine Frage. Und auf jeden Fall gibt es bei völlig unerwarteten Typen auch manchmal Fehlermeldungen, die eigentlich nicht so ganz zum Fehlerfall passen. Da muss man halt abwägen, wieviele Vorprüfungen (`isinstance()`-Checks) man einbauen will. Falls solche Zeilen zu sehr den Code aufblähen, dann ist der Wechsel zu einer Sprache mit statischer Typisierung vielleicht die bessere Lösung. Denn explizite Typprüfungen entsprechen eigentlich nicht der Philosophie, die hinter Python steckt. Das wäre dann mehr oder weniger ein Programmieren *gegen* die Sprache.
Oder geht es dir garnicht um tatsächlich auftretende Fehler, sondern nur um Gedanken an die theoretische Möglichkeit von Fehlerfällen?
Re: Best Practice? (because there is no type safety)
Verfasst: Mittwoch 15. August 2012, 08:44
von MaxMx
Mir geht es einfach nur um eine Unterstützung, um Interface Änderungen im ganzen Project durchzuziehen, trivialerweise zB das Ändern des Namens einer Funktion.
Die Codestellen, die ich anpassen muss, sind allesamt offensichtlich, und ich dachte mir, es muss doch ein tool geben, das das für mich hinbekommt (wenn ich schon keinen Compiler habe).
Grepen geht schon auch, aber das ist etwas mühsam, und man vergisst dann doch ein paar Stellen.
Unittests sind mir zu aufwändig, weil ich nicht die Korrektheit meines Programms testen will. Aber vielleicht ändert Python meine Meinung ja irgendwann

Ich schaue mir mal die oben genannten tools an, vielleicht ist da etwas dabei...
Re: Best Practice? (because there is no type safety)
Verfasst: Mittwoch 15. August 2012, 09:00
von deets
MaxMx hat geschrieben:
Die Codestellen, die ich anpassen muss, sind allesamt offensichtlich, und ich dachte mir, es muss doch ein tool geben, das das für mich hinbekommt (wenn ich schon keinen Compiler habe)
Das Gegenteil ist der Fall: *weil* du keinen Compiler hast, geht das nicht so, wie man das von statisch kompilierten Sprachen kennt.
Fuer mich reicht Emacs + rgrep, und ich finde alle Stellen... Und weil man eh weniger Code in Python schreibt als mit etwa C++ oder Java ist das auch alles nicht so wild.
Deine Einstellung zum testen solltest du aber wirklich ueberdenken. Und zwar nicht nur im Kontext von Python. Programmierer, die denken, wenn's kompiliert, dann laeuft's, gibt's ne Menge - genauso wie Laufzeitfehler in statisch typanalysierten Sprachen
Man muss also code-Aenderungen immer testen. Ich persoenlich schreibe mir lieber *einmal* einen Test dafuer, statt repititive Arbeiten bestaendig selbst zu machen.
Und bei konsequent testgetriebener Entwicklung wird auch das Design deutlich besser, denn man
- entwickelt nur, was man muss
- hat gleich die erste Anwendung seiner eigenen API
- erkennt, wo Schnitte zu setzen sind um zB Datenbanken oder andere Abhaengigkeiten von Komponenten zu abstahieren
Re: Best Practice? (because there is no type safety)
Verfasst: Mittwoch 15. August 2012, 10:07
von snafu
@MaxMx: Um was geht's dir denn jetzt?
Namensänderungen von Funktionen? - Da meckert Python durchaus, wenn beim Ausführen des Programms irgendwo noch ein alter Name benutzt wird, zu dem keine Funktion mehr existiert. Neben den schon genannten Tipps, könnte man hier - wie schon von dir eingangs angesprochen - eine IDE benutzen. An sich reicht aber auch simples Suchen+Ersetzen im verwendeten Editor aus.
Typänderungen der Argumente in der Funktionssignatur? - Auch das fällt wie gesagt schnell durch Exceptions auf.
Zeige doch mal ein "echtes" Beispiel, was dir Probleme macht. Denn andernfalls ist das IMHO tatsächlich nur als theoretisches Gedankenspiel zu betrachten bzw keiner weiß so recht, auf was du überhaupt hinaus willst. "90% Zeitverbrauch" sehe ich jedenfalls beim besten Willen nicht.
Im Übrigen hat Python durchaus einen Compiler. Der wird nur nicht explizit vom User aufgerufen, sondern Python kompiliert automatisch, wenn es merkt, dass es zu einer py-Datei keine passende/aktuelle kompilierte Version gibt. Kompilierten Code erkennt man übrigens an der Dateiendung `pyc`.
Re: Best Practice? (because there is no type safety)
Verfasst: Dienstag 21. August 2012, 15:56
von Leonidas
MaxMx hat geschrieben:Ich habe festgestellt, dass ich (vor allem bei 1 und 3) ne ganze Weile beschäftig bin, bis alles wieder korrekt läuft. Bei Sprachen wie C oder C++ meckert ja meistens der Compiler, dass etwas nicht stimmt.
Oder das Programm kompiliert und segfaultet einfach, ohne Traceback. Viel Spaß beim Debuggen.
Und Refactoring-Tools gibt es auch für Python, etwa
Bicycle Repair Man oder
Rope.