Gegenseitig voneinander abhängende Module

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
alan
User
Beiträge: 81
Registriert: Dienstag 10. April 2007, 11:30

Gegenseitig voneinander abhängende Module

Beitragvon alan » Sonntag 14. Oktober 2007, 10:16

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?
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Beitragvon mitsuhiko » Sonntag 14. Oktober 2007, 10:17

Setz die Imports ans Modulende.
TUFKAB – the user formerly known as blackbird
BlackJack

Beitragvon BlackJack » Sonntag 14. Oktober 2007, 10:27

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
User
Beiträge: 81
Registriert: Dienstag 10. April 2007, 11:30

Beitragvon alan » Sonntag 14. Oktober 2007, 10:42

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 :)
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Beitragvon Rebecca » Sonntag 14. Oktober 2007, 11:27

alan hat geschrieben: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.
Offizielles Python-Tutorial (Deutsche Version)

Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
BlackJack

Beitragvon BlackJack » Sonntag 14. Oktober 2007, 11:44

@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
User
Beiträge: 81
Registriert: Dienstag 10. April 2007, 11:30

Beitragvon alan » Sonntag 14. Oktober 2007, 11:45

Rebecca hat geschrieben: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. :wink:
Benutzeravatar
nkoehring
User
Beiträge: 543
Registriert: Mittwoch 7. Februar 2007, 17:37
Wohnort: naehe Halle/Saale
Kontaktdaten:

Beitragvon nkoehring » Sonntag 14. Oktober 2007, 13:35

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

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder