Schwierig? [Edit:] Wer rief die Methode auf?

[droptix]

@droptix: Ich verstehe immer noch nicht warum Du nicht den vorhandenen Code anpassen kannst. Du kannst das ja in einer Art und Weise tun, dass er für den bisherigen Zweck weiterhin funktioniert.

Theoretisch ja, aber ich müsste einen Haufen Code ändern. Das obige Bsp. zeigt ja nur einen kleinen Ausschnitt. Ich kann nicht ohne Weiteres einfach nur ein weiteres Argument an die Funktion übergeben, das müsste ich aber nochmal genau prüfen.

Aus dem von Dir gezeigten Quelltext wird das Problem übrigens IMHO in keinster Weise ersichtlich. Du hast da eine `as_csv()`-Funktion, der Du `account` *übergibst* und behauptest die einzige Möglichkeit dort heran zu kommen wäre dieses Stackframe-Voodoo, das den Wert an das Exemplar, an das der Aufrufer gebunden ist, bindet. Der Aufrufer *hat* dieses Objekt doch aber schon, sonst hätte er es nicht als Argument übergeben können!?

Nicht ganz: der Aufrufer (Instanz von `Accounting`) kennt ein gleichnamiges Objekt. Das ist aber eine Liste. In `as_csv` wird ein Dictionary erzeugt, an welches ich heran kommen muss.

Code: Alles auswählen

accounts = ["john", "jane"]
a = Accounting(ips, accounts)
# in `as_csv()`:
accounts[uid] = {"prints": prints, "copies": copies, "csv": csv}

@lunar: Ja, das kann ich nachvollziehen, wenn ich Code für andere schreibe. Da ich hier eine sehr spezielle Aufgabe mit einem nur dafür vorgesehenem Mittel lösen muss, ziehe ich "quick 'n' dirty" vor, weil mir dadurch viele Zeilen Code-Anpassung erspart bleiben... nicht nur weil ich von nataur aus faul bin sondern v.a. weil viel Anpassung auch viele neue Fehlermöglichkeiten bedeuten.

Krass übrigens, dass ich dafür so viel heftige Kritik einsammle... hätte nicht gedacht, dass man da so viel Wirbel drum macht Nichts für Ungut, kann damit umgehen, bin einfach nur überrascht. Ich hätte die Frage auch weniger kompliziert stellen können, aber dann wären mir die Auswirkungen vllt. nicht so einprägsam vermittelt worden. Danke also, ich werde das auch jeden Fall zukünftig berücksichtigen.

[Leonidas]

Krass übrigens, dass ich dafür so viel heftige Kritik einsammle... hätte nicht gedacht, dass man da so viel Wirbel drum macht Nichts für Ungut, kann damit umgehen, bin einfach nur überrascht.

Naja, was hast du erwartet? In der Python-Community wird stärker Wert gelegt auf gute Lösungen, nicht nur welche die irgendwie funktionieren, wie etwa in vielen PHP Communities. Siehe etwa die Threads mit problembär.

[BlackJack]

@droptix: In dem Quelltext den Du *gezeigt* hast, wird das Objekt übergeben und kein neues erzeugt.

Du bekommst so viel Kritik weil Du doch Code für andere schreibst. Entweder bist Du der ”andere”, wenn Du das Programm nach längerer Zeit wieder neu verstehen musst, oder es passiert etwas was angeblich nie passieren kann: Es muss tatsächlich mal jemand anders etwas an dem Quelltext machen. Viele von uns kennen das wahrscheinlich aus leidvoller Erfahrung, dass wir quick'n'dirty Quelltext von uns selbst nach einem Jahr nicht mehr wirklich verstehen, oder dass man Code von jemandem „erbt” der aussieht wie Kraut und Rüben. Da kommen dann Gefühle zwischen Hass und Verzweiflung auf.

Ausserdem tendieren solche Hacks dazu sich im Laufe der Zeit Schicht für Schicht anzusammeln. Und irgendwann hat man sich dann in eine Ecke manövriert wo der Quelltext schlicht nicht mehr wart- und erweiterbar ist, man das aber trotzdem machen muss. Was dann nicht selten auf wegwerfen und neuschreiben unter extremen Zeitdruck oder schlicht aufgeben hinaus läuft.

[Leonidas]

oder dass man Code von jemandem „erbt” der aussieht wie Kraut und Rüben. Da kommen dann Gefühle zwischen Hass und Verzweiflung auf.

Ausserdem tendieren solche Hacks dazu sich im Laufe der Zeit Schicht für Schicht anzusammeln. Und irgendwann hat man sich dann in eine Ecke manövriert wo der Quelltext schlicht nicht mehr wart- und erweiterbar ist, man das aber trotzdem machen muss. Was dann nicht selten auf wegwerfen und neuschreiben unter extremen Zeitdruck oder schlicht aufgeben hinaus läuft.

Haha, ich habe dazu einige kleine Anekdoten, und dabei habe ich bisher nur selten mit bestehenden proprietären Codebases arbeiten müssen.

Ich sollte eine Lib schreiben, die als Backend für ne GUI arbeitet, die ein Binärformat liest und schreibt. Dieser Teil wurde von Construct wunderbar übernommen (wenige dutzend Zeilen Code). Jedoch gibt es als Alternative zu diesem Binärformat auch ein etwas seltsames Textformat, zu dem es einen firmeninternen Parser gab und den ich nutzen sollte, da es zum Textformat keine Dokumentation gibt. Stellt sich aber raus, dass dieser Parser zu einer anderen Software gehört und diese Lizenzkeys verlangt, auch wenn man nur den Parser benötigt. Nachdem ich aufgegeben habe, verstehen zu wollen wie dieser Parser auf abenteuerliche Weise funktioniert und es auch nicht besonders schön fand dem Programm ein Lizenzfile mitzugeben, welches eben auch die andere Software "freischalten" würde, wurde letztendlich das die ganze Funktionalität raus-gemonkey-patched, so dass die meine Verifikations-Methode immer sagte, dass die Lizenz da ist, und ich diesen Parser verwenden konnte.

Das kommt davon wenn man zu seltsamen Code schreibt, der irgendwie über ganz seltsame Art ineinanderverwickelt ist.

Die andere Story möchte ich auch nicht vorenthalten: dieser Parser konnte nämlich auch diese Dateien in dem Format rausschreiben. Genau einmal. Danach war das Objekt auf irgendeine Weise modifiziert, irgendwelche Felder würden gelöscht oder resettet, so das das Objekt unbrauchbar war. Die einfache Lösung wäre, einfach ein neues Objekt anzulegen, aber leider war nicht nur das Objekt danach kaputt sondern noch mindestens die zugehörige Klasse oder auch der ganze Interpreter. Ich habe aufgegeben, das zu analysieren (weil das fixen der Codebase war nicht mein Job) und dann multiprocessing rausgepackt und diese Funktionalität immer an einen "frischen" Interpreter delegiert.

Ja, beides bizarre und furchtbare Hacks. Sowas sollte man auf jeden Fall vermeiden, irgendwelche "klugen" Optimierungen, die sich dann später als Fluch herausstellen.

[lunar]

@droptix: Ergänzend zu BlackJack: Suche mal nach der "Broken Windows"-Theorie im Bezug auf Software Engineering. Das Phänomen, dass kleine, unschöne Lösungen über die Zeit kumulieren und schlussendlich die Qualität des gesamten Quelltexts stark absinken lassen, ist sogar empirisch untersucht und wissenschaftlich beschrieben. Wenn wir Dir nachdrücklich vor solchen Lösungen abraten, geschieht das mithin weder, um Dich zu ärgern noch um Dich zu provozieren.

Es ist letztlich Deine Entscheidung, doch erwarte nicht allzu viel Verständnis dafür, spätestens, wenn Du hier in einem halben Jahr wegen eines Problems nachfragst, welches durch diesen Hack verursacht wurde.