import, execfile(), subprocess & Co. >> Übersichtlichkeit von Varianten, Code in externe py auslagern, einbinden..

[m__golbs]

Hallo,

ich habe variantenreiche Rechnungen zu realisieren. Im Kern könnte ich dass alles in eine *.py klatschen, nur bei tausenden Zeilen Code und vielen "langen" Variantenrechnungen macht das irgend wie keinen Sinn, Übersichtlichkeit, Fehlersuche, Anpassungen, Pflege, Verbesserungen...

Nun dachte ich mir, einfach den x*Variantencode (im Kern nach gleichem Strickmuster...) in externe py's packen und mit import einlesen, ausführen, den Kerncode als mail.py nutzen... Nur da habe ich folgende Aufgaben zu lösen ein Problem..
- Die Varianten.py's müssen alle bekannten Variablen der main.py (welche vorher gelaufen sind bekommen) übergeben bekommen. Wie geht das Gibt es da einen globale Übergabemöglichkeit, sys.argv[0]...?

Könnte man die externen py's als "Quellcode in die main.py an die jeweilige Stelle einfach einlesen, ohne import, execfile(), subprocess & Co. ...?

Gruß und Dank Markus

[Sirius3]

@m__golbs: Deine Probleme fangen schon früher an. Du hast globale Variablen. Das verhindert, dass Du Dein Programm sauber strukturieren kannst. Erster Schritt wäre es also, Deine "Varianten" in Funktionen umzuschreiben, die nur mit den Variablen arbeiten, die sie als Argumente übergeben bekommen. Sobald Du alles in Funktionen aufgeteilt hast, ist es auch kein Problem mehr, einzelne Funktionen in Module auszulagern.

[m__golbs]

Hallo,

danke für die Antwort. Das ist leider so nicht einfach möglich, weil ständige Interaktionen, Fallunterscheidungen zwischen globalen Variablen und Funktionen notwendig wären/sind. Dann wird auch permanent zwischen den x*Variantencode in den Datensätzen gewechselt. "..alles in Funktionen aufgeteilt hast, .." Wird mich in den Wahnsinn treiben

Ich denke ich werde folgenden Weg gehen:
- Main.py.Vorlage schreiben (globale Daten, Datenhandling,..)
- Varianten.py's schreiben
- Einen Code schreiben, der dann aus diesen Einzel Pseudo-py's eine riesige lauffähige, temporäre main.py für einen einzigen Lauf erzeugt. Damit bleibt es pflegbar und trotzdem modular.


Gruß und Dank Markus

[__blackjack__]

@m__golbs: Wie können einen Funktionen in den Wahnsinn treiben, tausende Zeilen unstrukturierter Code mit globalen Variablen aber *nicht*‽ So etwas strukturiert man doch normalerweise ein Funktionen um den Wahnsinn zu beenden.

[m__golbs]

Hallo,
"..tausende Zeilen unstrukturierter Code mit globalen Variablen aber *nicht*‽.." Richtig, auch diese müssen gut durchdachte, sinnvolle Strukturen und Zusammenhänge aufweisen, für den Anwendungsfall das richte Maß "Aufwand, Nutzen und Anwendungsorientierung bieten". Wenn man daran denkt, dass 100 externe Funktionen interagieren sollen, wird das auch nicht simple, besonders wenn die dann doch noch dieses und jedes schnell mal können sollen.. Mal sehen wo ich später mit der Einschätzung stehen werde.

Gruß Markus

[sparrow]

Wenn du denkst, dass du auf globale Variablen nicht verzichten kannst, dann brauchst du dir über Übersichtlichkeit keine Gedanken machen. Das ist verschwendete Lebenszeit.

[grubenfox]

In main.py eine Klasse Kernprogramm (mit dem Kernprogramm) schreiben, die Varianten-Funktionen aus den verschiedenen varianten.py in main.py mit import importieren und in den Methoden der Kernprogramm-Klasse einfach nutzen...
Wie schon geschrieben werden die Variablen beim Aufruf der Varianten-Funktionen einfach übergeben.

Ich bin jetzt nicht sicher ob das einem nicht irgendwann in der Zukunft kräftig in den Allerwertesten tritt, aber geht...

[Sirius3]

@m__golbs: ich weiß nicht, welche Vorstellungen Du von Funktionen hast. Eine Funktion hat eine Aufgabe, da dürfen nicht 100 Funktionen miteinander interagieren. Eine Funktion ruft eine andere auf, um ein Ergebnis zu erhalten, mit dem man weiter arbeiten kann.
Bisher waren Deine Fragen sehr unkonkret. Bisher habe ich noch keinen Code gesehen, der nicht durch Funktionen wesentlich besser geworden wäre, als 1000 Zeilen ohne Funktionen.
Also zeige Deinen Code, dann können wir Dir auch helfen.

[__blackjack__]

@m__golbs: Funktionen interagieren über die Parameter, alles was ausser Konstanten benötigt wird, und den Rückgabewert, der auch ein Tupel oder ein komplexeres Objekt sein kann. Letztlich hast Du das beim bisherigen Code ja auch, nur dass das nicht als deutliche Schnittstelle sichtbar ist, was eben auch schon ein Nachteil ist wenn man *keine* Funktionen verwendet.

Durch Funktionen kommt dann neben der deutlichen Schnittstelle auch gleich der Vorteil der Testbarkeit. Was bei der Fehlersuche hilft, weil man jetzt nicht mehr das ganze Programm betrachten muss, sondern einzelne Funktionen separat testen kann.

Man kann automatisierte Teste gegen Funktionen schreiben, so dass man die einfach wiederholen kann, zum Beispiel um sicherzustellen, dass bei Änderungen am Code nichts kaputt gegangen ist.

[DeaD_EyE]

Globale Variablen sind eine Seuche, wenn es darum geht ein Programm zu entwickeln, dass später durch andere erweitert werden soll.

Für ein Wegwerfscript ist das OK, wenn man den Code nur selbst nutzt.
Wenn aber andere damit arbeiten müssen, ist das die Hölle.

Würde mich nicht wundern, falls schlechter Code auch eine Ursache für das Burnout-Syndrom ist.

Mögliche Ansätze (keine Lösung):
- Eine Basis-Klasse, die alle Gemeinsamkeiten festlegt und dann spezialisierte Klassen, die von der Basis-Klasse vererben.
- Wenn es sehr viele Ausnahmen und Regeln gibt, diese ggf. in einem anderen Format speichern und dann programmatisch einlesen (CSV, JSON, TOML, YAML, ....).

[grubenfox]

Globale Variablen sind eine Seuche, wenn es darum geht ein Programm zu entwickeln, dass später durch andere erweitert werden soll.

... und Programmiersprachen bei denen Variablen per Default global sind. Ich dachte ja mal, dass die Menschheit diese Katastrophe irgendwann in den 70er oder 80ern hinter sich gelassen hätte. Musste dann aber erfahren dass es mindestens bei Lua (von 1993) noch immer so ist...

[__blackjack__]

Ergänzend zu DeaD_EyE: ”Andere” ist man nach einer gewissen Zeit auch selbst, wenn man sich nach Monaten oder Jahren wieder in den (eigenen) Code einarbeiten muss. Ganz vieles an Zusammenhängen was beim schreiben noch frisch in Erinnerung war, ist dann nämlich weg und man muss sich das alles wieder mühsam erarbeiten.

@grubenfox: Bei Lua könnte man noch anführen, dass das als minimalistische Skriptsprache zum Einbetten in andere Programme oder in wirklich kleinen Systemen gedacht war/ist. Man kann das auch heute noch für Systeme übersetzen wo ``int`` nur 16 Bits hat. Für DOS beispielsweise.