Gegenseitig voneinander abhängende Module

[alan]

Hallo

folgende Situation:
app.py enthält die eigentliche Programmlogik. gui.py importiert app.py und bastelt die Gui drum herum.
Zur Gui kommt jetzt allerdings noch ein sehr großer Dialog hinzu, den ich gern in ein eigenes Modul verschieben würde. Aber: Dieses gui_dialog.py würde sowohl von app.py als auch von gui.py abhängen. Andererseits soll gui_dialog schließlich in gui.py eingebunden werden.
Ich weiß nicht wirklich viel über die Python Interna diesbezüglich, aber mir ist das Konzept dieser kreisförmigen Abhängigkeiten ziemlich unsympathisch.

Kann man das trotzdem problemlos so machen oder sollte ich lieber davon absehen, den Dialog in gui_dialog.py auszulagern?

[mitsuhiko]

Setz die Imports ans Modulende.

[BlackJack]

Solche kreisförmigen Importbeziehungen sollte man vermeiden. Wenn sich zwei Module gegenseitig importieren sind sie so stark voneinander abhängig, dass sich die Frage stellt warum sie nicht in einem Modul stecken.

Warum braucht das Dialogmodul das GUI-Modul denn überhaupt?

[alan]

Ok, dann werde ich das mal lassen.

Wie sieht es denn aus, wenn gui_dialog.py nur von app.py abhängt?
Soweit ich es verstehe, wird app.py dann zweimal importiert, einmal von gui.py und dann von gui_dialog.py, wenn es von gui.py eingebunden wird. Ist das akzeptabel, nur um den Code logisch etwas zu trennen?

Und was würden Importanweisungen am Modulende bewirken?

Und: Gibt es irgendeine Möglichkeit, dass gui_dialog.py einfach den Namespace von gui.py übernimmt? Sprich: gui_dialog.py muss app.py nicht importieren, ist dafür aber auch nur lauffähig, wenn es von gui.py importiert wird.

Viele Fragen

[Rebecca]

Soweit ich es verstehe, wird app.py dann zweimal importiert, einmal von gui.py und dann von gui_dialog.py, wenn es von gui.py eingebunden wird. Ist das akzeptabel, nur um den Code logisch etwas zu trennen?

Vorausgesetzt, ich habe dich richtig verstanden: Klar. Egal wie oft du die import-Anweisung hinschreibst, ein Modul wird immer nur einmal importiert.

[BlackJack]

@alan: Importanweisung am Modulende bewirkt, dass der Import erst am Ende ausgeführt wird, nachdem alles was davor steht ausgeführt wurde.

Wenn das Dialog-Modul den gleichen Namensraum wie das GUI-Modul benutzen würde, bleibt wieder die Frage warum dann überhaupt ein eigenes Modul. Modul == eigener Namensraum. Wenn man das nicht möchte, dann sollte man entweder nachdenken, ob man ein eigenes Modul haben möchte, oder ob der Code nicht zu eng gekoppelt ist und vielleicht etwas modularer geschrieben werden kann.

Die "Verbindung" sollte eher über Objekte und nicht über Module erfolgen. Wenn der Dialog etwas aus dem GUI-Modul braucht, dann kann man das auch beim Aufruf übergeben und hat damit keine feste Kopplung zwischen den Modulen mehr.

[alan]

Egal wie oft du die import-Anweisung hinschreibst, ein Modul wird immer nur einmal importiert.

Hmm..:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-d

# app.py

print "Ich bin app.py"

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-d

# gui.py
import app
import gui_editor

print "Ich bin gui.py"

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-d

# gui_editor.py
import app

print "Ich bin gui_editor.py"

Ich bin app.py
Ich bin gui_editor.py
Ich bin gui.py

Du hast Recht Thx

@BlackJack
Danke, ich glaube jetzt verstehe ich das Modul-Konzept um einiges besser.

[nkoehring]

Hi Alan!

Weiß nicht ob dir das hilft, aber ich verwende fuer Dinge Kreisabhaengigkeiten erzeugen wuerden meist extra-Module.

Gerade wenn man bei wxPython Events oder globale Variablen (app, top_frame, etc sind oft sehr nuetzlich) hat, die man ueberall direkt ansprechen koennen soll, lagere solche Sachen lieber in ein unabhaengiges Module, dass selbst keine weiteres (programminternen) Abhaengigkeiten hat.

Man koennte auch eine Art "Datamanager-Klasse" bauen, die von ueberall mit Daten gefuettert wird und diese ueber alle Instanzen (also als Klassenvariable) anbietet... da muss man dann aber sehr genau aufpassen, das die Variablen auch immer schon gesetzt sind (aber auch das kann man ja der Klasse beibringen).

Gruß
NKoehring