Kurze Frage zum Debuggen mit pycharm (oder andere Debugger)

[Papageno]

Es schwärmt ja vieles von den Debuggerfähigkeiten von pycharm. Ich arbeite seit ein paar Tagen damit. Aber was macht den Debugger soooo toll. Als VB versauter SemiProgrammer suche ich die Funktion um während des Debuggens den Quelltext ala´ VB zu editieren und meinen trial and error Stil weiterzubetreiben. Oder muss ich mich da gewaltig umstellen?

[BlackJack]

@Papageno: Ich würde sagen: gewaltig umstellen. Vielleicht auch mal überlegen wozu man einen Debugger überhaupt braucht. Ich finde solche Einzeschrittdebugger in Hochsprachen zunehmend überflüssig beziehungsweie sogar nicht sinnvoll anwendbar. Die Situationen in denen ich früher, oder auch heute noch, durch eine Funktion „steppe” haben immer mit weniger ausdrucksstarken Sprachen zu tun in denen es überhaupt Funktionen gibt mit so vielen „beweglichen” Einzelteilen dass man das nicht mehr sinnvoll ohne einen Debugger durchlaufen könnte. Bei Python würde ich in solchen Situationen eher davon ausgehen das die Funktion komplett neu geschrieben werden sollte. Oder sie ist zu umfangreich und sollte auf mehrere aufgeteilt werden.

Python-Entwicklung geht üblicherweise ganz grob gesehen so vonstatten das man Sachen in einer Shell ausprobiert, dann kleine Funktionen schreibt und die dann testet, entweder auch in einer Shell oder automatisiert mit Unit-Tests, und die getesteten Funktionen dann in neuen Funktionen verwenden, die wieder testen, bis man das Gesamtproblem gelöst hat und bei einer `main()`-Funktion angekommen ist.

In Python reichen in der Regel ein paar strategisch platzierte ``print``\s aus um zu überprüfen die Werte die man erwartet an einer bestimmten Stelle auch so aussehen. Oder eine Debug-Ausgabe über das `logging`-Modul. Etwas dauerhafter kann man für Invarianten auch ``assert`` zum prüfen verwenden.

[Papageno]

@BlackJack: Kann dir und den beschriebenen Schritten schon folgen. Ich sehe da aber Probleme mit größeren Programmen, die erst eine gewisse Anzahl von Eingaben und Daten brauchen, bevor man an die problematische Stelle kommt. Da glaube ich, momentan zumindest, mehr Zeit als bisher zu benötigen. Ja, mit der print Anweisung lässt sich vieles machen, so hat mein derzeitiges und erstes Projekt mehr print Ausgaben als Code . Nun kann ich dank deiner Aussage dabei bleiben, es gibt ihn einfach nicht den VB-Debugger unter Python. Den Begriff assert lese ich zum ersten Mal, muß meine Pybel auspacken und den Psalm dazu suchen
Na ja, bin ja erst am Anfang. Und aller Unkenrufen zum Trotz habe ich in nahezu 2 Wochen von Null weg ein brauchbares Programm mit Qt und anderen Snacks gebacken. Also, Spaß macht das Pythonieren schon. Das Forum ist auch eine gute Quelle für Peilungsversuche. Besten Dank an dieser Stelle an alle Autoren und Moderatoren. Auch wenn ich seit gestern daran verzweifle um pyodbc o.ä. zum Laufen zu bekommen. Aber das wird dann wahrscheinlich morgen ein eigener Thread.

[darktrym]

Du kannst einen Haltepunkt setzen und dann in einer Konsole online Ausdrücke testen(Debugfenster, Taschenrechnersymbol), ähnlich dem Konzept von Matlab. Das gleiche kann man auch erreichen mittels pdb.
VB kenn ich nicht, war das jemals irgendwo in Verwendung?

[BlackJack]

@Papageno: Auch grössere Programme bestehen ja aus kleineren Teilen, und wenn die ordentlich getestet werden bevor man sie verwendet, dann kommen Fehler nicht sooo oft vor. Bei grösseren Programmen schreibt man normalerweise ja auch Unit-Tests und macht sich da Gedanken über die ganzen Randfälle an denen komische Sachen passieren könnten. Das hat man, zumindest soweit ich das noch in Erinnerung habe, bei VB nicht gemacht. Da waren die Programmlogik und die GUI auch oft so verwoben das man gar nicht sinnvoll testen könnte.

[/me]

VB kenn ich nicht, war das jemals irgendwo in Verwendung?

Bei VB (bzw. VBA) kannst du während des Debuggens den Code ändern. Das geht, da VB in dem Fall als strunzdummer Interpreter agiert.

[BlackJack]

Mindestens bei Eclipse geht für Java „hot code replacement” in bestimmten Fällen wenn man während des Debuggens den Quelltext ändert und bei Smalltalk ist Programmieren in dem man sich im Debugger von Fehler zu Fehler steppt und da dann weiterprogrammiert eine Technik die von einigen aktiv betrieben wird.

[Papageno]

Mindestens bei Eclipse geht für Java „hot code replacement” ...

Das war das Stichwort! Es geht auch unter Python hot swapping. Das muss ich mal probieren. Jetzt stehen leider erst noch andere Baustellen an.

..Das geht, da VB in dem Fall als strunzdummer Interpreter agiert

VB ist nicht Dümmer als sein Programmierer , es ist halt extreme rapid engineering und extreme learning by doing. Jetzt bin ich mit 4kg Büchern und Internet unterwegs, als ich mit VB anfing gabs nur das VB Handbuch und die F1 Taste. Ich denke aber mit zunehmender Pythonerfahrung schwindet der Vorteil. Und das Verlangen nach Debugging.

[jens]

Ich sehe da aber Probleme mit größeren Programmen, die erst eine gewisse Anzahl von Eingaben und Daten brauchen, bevor man an die problematische Stelle kommt.

Deswegen mache ich gern auch "unitests" die nicht nur eine kleine "unit" testen, sondern ganz vorn Daten rein stopfen und ganz hinten kontrollieren, ob vernünftiges raus kommt...
Ist bei Web-Anwendungen allerdings einfacher als bei GUI-Programmen...

[/me]

..Das geht, da VB in dem Fall als strunzdummer Interpreter agiert

VB ist nicht Dümmer als sein Programmierer , [...]

Das war auch nicht abwertend gemeint. Das klassische VB(A) selber ist eine extrem hässliche Sprache, aber die Debugging-Möglichkeiten sind schon nett.

[Sirius3]

@/me: dann hast Du aber noch nie einen Fehler in tausenden Zeilen Excel-Makro gesucht.

[Papageno]

Das war auch nicht abwertend gemeint. Das klassische VB(A) selber ist eine extrem hässliche Sprache, aber die Debugging-Möglichkeiten sind schon nett.

Das habe ich auch nicht abwertend verstanden Ich habe nur fast 30 Jahre nix anderes gemacht. Bin nur Gelegenheitsprogrammierer mit ambitionierten Ideen, da kanns mal 10 Jahre dauern bis eine Software fehlerfrei läuft

[BlackJack]

@Papageno: Das „hot swapping” aus dem verlinkten SO-Beitrag bezieht sich auf ganze Module und es betrifft auch nur neu erstellte Objekte aus dem Modul. Das ist im Grunde nur ein Plugin-Mechanismus wo man zur Laufzeit Plugins noch mal neu laden kann. Mit all den Problemen die man dabei dann haben kann, eben zum Beispiel dass das keinen Einfluss auf bereits aus dem alten Modul erzeugte Objekte hat. Wenn man in Smalltalk im laufenden Programm eine Klasse verändert dann hat das dort auch Auswirkungen auf alle bestehenden Exemplare von dem Typ, weil man eben *die* Klasse davon verändert — was auch Probleme nach sich ziehen kann.

Es ist auf jeden Fall nicht allgemein einsetzbar. Wenn Du dynamisch ladbare und auch erneut ladbare Plugins in Deinem Programm haben möchtest, dann ist das vielleicht interessant, aber viele Programme haben und brauchen so etwas nicht. Und man muss sich Gedanken um die Folgen davon machen und zum Beispiel noch aktiv selber dafür sorgen das keine Reste von der vorherigen Version des Moduls im laufenden Programm herumgeistern und damit vielleicht zu komischem und inkonsistenten Verhalten führen.

[Papageno]

@BlackJack. Danke für die fürchterlich ernüchternde Aufklärung. Werde wohl besser an einem allgemein anderen Programmierstil arbeiten. Das mit dem Testen in der Konsole und dann ins Programm integrieren klingt ja auch interessant. Jetzt habe ich aber erstmal Installationsprobleme :K , ein neuer Thread entsteht