Probleme bei der Einbindung von SubModulen in ein Programm

[Papp Nase]

Herzlichen Dank für Deine ausführliche Antwort - ich habe mich sehr drüber gefreut.

Bei b) denke ich an das ``Arbeitsverzeichnis/`` aus Deinem Beispiel das dadurch nur *ein* Package hat in dem alles andere als Subpackages liegt, wo Du aber eigentlich ja gesagt hast das sind unabhängige Projekte.

Graphenanzeige habe ich als ein unabhängiges "Projekt" entwickelt. Und ich habe noch weitere Elemente selber als Projekte hergestellt, z.B. eine Menüleiste. Diese einzelnen Elemente funktionierten.


Es gibt also jetzt folgende Verzeichnisse:

C:\Pythonprojekte\MeineBibliothek\graphenanzeige
C:\Pythonprojekte\MeineBibliothek\menueleiste

Ich hab aber auch im Verzeichnis C:\Pythonprojekte\MeineBibliothek\ brav eine Datei __init__.py abgelegt. Und tatsächlich existiert auch im Verzeichnis C:\Pythonprojekte\__init__.py. Und natürlich auch in C:\Pythonprojekte\MeineBibliothek\graphenanzeige\__init__.py und auch in Graphenanzeige\data\__init__.py

Also - so wie ich es jetzt kapiert habe - erstelle ich mit __init__.py ein Projekt. Wenn also Graphenanzeige ein Projekt sein soll, dann darf nicht im Verzeichnis C:\Pythonprojekte\MeineBibliothek\__init__.py vorhanden sein, weil sonst auch MeineBibliothek als ein Projekt aufgefasst wird?

Muss ich denn dann auch die Datei C:\Pythonprojekte\MeineBibliothek\graphenanzeige\data\__init__.py haben - oder dort dann nicht mehr? Also setze ich die __init__.py nur in dem Startverzeichnis von dem eigenständigen Modul/Projekt - oder auch in den dazugehörigen Unterverzeichnissen?

[BlackJack]

@Papp Nase: Eine ``__init__.py`` macht ein Verzeichnis nicht zu einem Projekt sondern zu einem Package, beziehungsweise Subpackage wenn im Verzeichnis darüber auch schon eine ``__init__.py`` liegt. Und so eine Datei muss in allen Verzeichnissen liegen über die man etwas importieren möchte, damit Python weiss, dass es sich um ein Package handelt und vor allem auch was denn der Inhalt des Packages selber ist, denn man kann ja nicht nur Module aus einem Package importieren, sondern auch das Package als solches. Auf oberster Ebene eines Packages würde ich da zum Beispiel mindestens Metainformationen wie Dokumentation und Attribute wie `__version__`, `__author__`, und vielleicht auch `__licence__` erwarten. Nicht selten werden in der ``__init__.py`` auch die Objekte die zur offiziellen API gehören aus den Modulen und Subpackages importiert und damit sozusagen auf dieser Ebene ”re-exportiert”.

Falls alle Deine ``__init__.py`` leer sind, könnte man das übrigens eventuell auch als vergeudeten Namensraum auffassen.

Wenn ``graphenanzeige/data/`` ein (Sub)Package sein soll, man es also selbst oder Module daraus importieren können soll, dann muss da eine ``__init__.py`` drin stehen.

[Papp Nase]

Vielen Dank für Deine Antwort, über die ich mich sehr gefreut habe.

Auf oberster Ebene eines Packages würde ich da zum Beispiel mindestens Metainformationen wie Dokumentation und Attribute wie `__version__`, `__author__`, und vielleicht auch `__licence__` erwarten.

Diese Metainfos - __author__ = xxx - soll ich die dann am besten in die __init__.py für das jeweilige Modul reinpacken? Also z.B. in /graphenanzeige/__init__.py, weil das dann für mein Modul Graphenanzeige gelten soll?

[BlackJack]

@Papp Nase: Ja, diese Metainformationen findet man normalerweise in dem obersten Package eines Projekts/einer Bibliothek. Und das gilt dann für das gesamte Package inklusive Unterpackages. Die haben ja selten noch mal eigene Versionen oder Autoren.

[Papp Nase]

Vielen Dank für Deine Antwort. Ich habe jetzt auch das eine oder andere zu der __init__.py gelesen. An einer Stelle hab ich es so verstanden, dass die __init__.py auch ausgeführt wird und man dort auch z.B. import-Befehle hineintun könnte, die dann für das ganze Packageprojekt gültig sein sollen.

Ich hab jetzt z.B. in die Datei /graphenanzeige/__init__.py hineingeschrieben "from graphenanzeige.data.fofo import FIFO", weil ich das auch in der Datei /graphenanzeige/start.py stehen hatte und ich dachte, wenn ich es in die __init__.py hineinschreibe, dass ich es dann nicht mehr in den einzelnen .py-Dateien machen brauche - aber das hat nicht geklappt.

[BlackJack]

@Papp Nase: Alles in der ``__init__.py`` gilt nur für das ”Package-Modul” und für nichts anderes. Mit einem ``from graphenanzeige.data.fofo import FIFO`` in der ``graphenanzeige/__init__.py`` erreicht man das das `FIFO`-Objekt aus `graphenanzeige.data.fofo` auch in `graphenanzeige` unter diesem Namen abrufbar ist.

[Papp Nase]

@Papp Nase: Alles in der ``__init__.py`` gilt nur für das ”Package-Modul” und für nichts anderes. Mit einem ``from graphenanzeige.data.fofo import FIFO`` in der ``graphenanzeige/__init__.py`` erreicht man das das `FIFO`-Objekt aus `graphenanzeige.data.fofo` auch in `graphenanzeige` unter diesem Namen abrufbar ist.

Vielen Dank für Deine Antwort.

Ok, ich lasse das lieber, in diese __init__.py´s etwas reinzuschreiben, ich glaube, es ist besser, wenn ich es sauber in den Modulen direkt reinschreibe.

Ich habe jetzt aus meiner Datenstruktur C:\Pythonprojekte\MeineBibliothek\ die __init__.py gelöscht und nur noch in den einzelnen nachfolgenden Verzeichnissen wie /graphenanzeige oder /xyz eine __init__.py drinnen. Ich hab jetzt mein Arbeitsverzeichnis auf das aktuelle Projektverzeichnis gelegt, in das ich die Module hineinladen möchte und in einen anderen Verzeichnis-Strang, wo \MeineBibliothek ... drinnen ist, da habe ich den Pfad "external libs" draufgesetzt in der Programmierumgebung und jetzt findet er die Module und auch, wenn ich in dem Modul der Übersichtlichkeit halber auch wieder ein Unterverzeichnis hab und das "graphenanzeige.data.fifo" aufrufe, dann findet er es. Scheinbar lag es dann wirklich an "zu vielen" __init__.py-Dateien.

[BlackJack]

@Papp Nase: So wie Du das beschreibst kannst Du das Programm dann nur aus der IDE heraus starten, denn die „external libs”-Einstellung gilt ausserhalb ja nicht.

[Papp Nase]

@Papp Nase: So wie Du das beschreibst kannst Du das Programm dann nur aus der IDE heraus starten, denn die „external libs”-Einstellung gilt ausserhalb ja nicht.

och menno, jetzt war ich grade so froh, dass ich es unter der IDE zum Laufen gekriegt habe und jetzt ist es immer noch nicht richtig

Und wenn ich mein Verzeichnis /MeineBibliothek in das Verzeichnis

/python34/lib/MeineBibliothek hin kopiere? Dort sind ja auch die ganzen anderen Dinger. Ich hab auch extra jetzt geschaut, in dem Verzeichnis /Python34/lib gibt es keine __init__.py, nur in den Unterverzeichnissen wie /lib/distutils/__init__.py ...

Würde das funktionieren dann?

In der IDE gibt es diesen Pythonpath. Aber der Pythonpath ist keine Systemvariable, weil ich die nicht gefunden hab.

[cofi]

In der IDE gibt es diesen Pythonpath. Aber der Pythonpath ist keine Systemvariable, weil ich die nicht gefunden hab.

Doch, PYTHONPATH ist eine Systemvariable, das sagt sogar das Tutorial beispielsweise hier: https://docs.python.org/2/tutorial/modu ... rd-modules

Aber PYTHONPATH muss es bevor du sie erstellst nicht zwingend geben.

[Papp Nase]

Vielen Dank für die Antwort.

Hab ich das jetzt richtig verstanden - wenn ich mir selber einen Pythonpath setze - bevor der Interpreter gestartet wird, dann klappert der bei der Suche nach Modulen den ganzen Pfad ab? Ich müsste mir dann "einfach" den Pythonpath so setzen:

Code: Alles auswählen

set pythonpath=C:\...\meinHauptprogramm;C:\...\meineModule;

[Papp Nase]

cool, ich hab das mal mit dem Pythonpath grade ausprobiert - und es funktioniert