Laden von eigenen Modulen über einen Objekt - Manager

[YAPD]

Ich habe ja nachdem ich mal gesucht hatte, weil mir dieser ObjectManager so bekannt vorkam, irgendwie das Gefühl YAPD sollte sich einfach mal auf Python einlassen, statt zu versuchen Perl-Nomenklatur und -Semantik irgendwie in Python prügeln zu wollen.

Hier ist das Original von 2021: viewtopic.php?p=391088#p391088

Die Begriffe Package, Module, Class, Methods werden da im Code verwendet wie Perl das handhabt, wo ein voll qualifizierter Name mit "::"-Trennern ein Package ist, Modul und Klasse im Grunde das gleiche sind, und Methoden einfach Funktionen in einem Modul sind. Python ist halt nicht Perl.

Danke für die "Hilfe" und dafür, dass du mich 2 Seiten lang belehrt hast, anstatt mir einen Tipp für eine funktionierende Lösung zu geben, die im Prinzip nur aus Änderungen von 2 Zeilen im Zusammenhang mit importlib stehen. Aber da importlib ja mit dem allen gar nichts zu tun hat, kann das ja nicht sein.
Es gibt viele Python - Foren, in dem die User viel freundlicher und hilfsbereiter seid, als ihr "Experten". Und
das zieht sich durch jeden Post von Euch auf dieser Seite. Erstmal 2 Seiten lang über jeglichen Mist beschweren anstatt zu helfen.

[pillmuncher]

Ganz oben in deinem ersten Post in diesen Thread hast du geschrieben:

Hintergrund ist, dass ich so auch direkt Klassen aus den Modulen aufrufen kann.

Warum verwendest du nicht den normalen Weg und importierst einfach alles, was du brauchst, am Anfang eines Moduls? Guckstu:

Code: Alles auswählen

import foo
from bar import Baz

...<irgendwas mit foo.bla>...

...<irgendwas mit Baz>

Und wenn es nur darum geht, alles über ein einziges import-Statement in jedem Modul zu bekommen (weil Bytes sind ja wegen der Inflation so teuer geworden), dann macht man das so:

Code: Alles auswählen

# Modul <app-root>/__init__.py
...

# Modul <app-root>/foo.py
def bla(...):
    ...

# Modul <app-root>/bar.py
class Baz:
    ...

# Modul <app-root>/all_in_one.py
from .foo import bla
from .bar import Baz

# Modul <app-root>/irgendwas.py:

from .all_in_one import bla, Baz

Wer darüberhinaus irgendwelche Mechanismen für den Import braucht, weiß entweder genau warum und wie man das bewerkstelligt, oder er braucht es eben doch nicht.

[YAPD]

Hey Phil,

vielen Dank für deine Antwort. Ich werde versuchen, es entsprechend mit
deiner Lösung zu realisieren und würde mit Fragen auf dich zukommen.

Ganz oben in deinem ersten Post in diesen Thread hast du geschrieben:
Hintergrund ist, dass ich so auch direkt Klassen aus den Modulen aufrufen kann.
Warum verwendest du nicht den normalen Weg und importierst einfach alles, was du brauchst, am Anfang eines Moduls?

Ich denke, dass es mir darum ging, dass mir die Import Funktion zu automatisch war &
ich über den Objekt Manager noch verschiedene Dinge steuern kann.

Wer darüberhinaus irgendwelche Mechanismen für den Import braucht, weiß entweder genau warum und wie man das bewerkstelligt, oder er braucht es eben doch nicht.

Das letzte Problem, dass ich hatte war, dass ich keine Datei "Config.py" und gleichzeitg
einen Ordner namens Config im gleichen Verzeichnis verwenden kann, weil die Namen
kollidieren. Ich habe das aber schon in den Griff bekommen.
Würde das mit deiner Lösung auch funktionieren ?

VG
YAPD

[sparrow]

Das liegt daran, weil du noch nicht verstanden hast, was Module in Python sind und wie die sich darstellen.
Aber anstelle hier auf die Leute zu hören, die dir nicht erst seit diesem Thread sagen, dass du auf dem Holzweg bist, verrennst du dich da etwas sehr.
Und nach dem eigentlich Sinn, warum du glaubst, den Import-Mechanismus neu zu erfinden, wurdest du nun ja häufig gefragt. Eine Antwort bist du schuldig geblieben. Aber es steht jedem frei, auf einem Irrweg zu sein. Und jedem ihm das deutlich zu sagen.

Schau doch mal in die Dokumentation zu modules um zu verstehen wie Module funktionieren.

Eine vernünftige Namensgebung und ggf. Paketierung von Modulen hilft sehr, gar nicht erst in die Verlegenheit zu kommen, dass Module gleich benannt sein können.

[__blackjack__]

@YAPD: Letztlich hast Du immer noch nicht verraten welches Problem Du eigentlich lösen willst, und da Du offensichtlich noch Wissenslücken hast wie Importe in Python funktionieren, weisst Du ja noch nicht einmal ob Deine Annahmen stimmen, dass Du da unbedingt was eigenes basteln musst.

Man hat einfach keine ``config.py`` im gleichen Verzeichnis wie ein Verzeichnis Namens ``config/``, denn so ein Verzeichnis ist in Python dann (mindestens ein Namespace-)Package und ein ``import config`` ist dann nicht mehr eindeutig, ob man da dann den Inhalt des Packages als Modul bekommt, oder den Inhalt des Moduls. Der Tipp dazu war den Inhalt von der ``config.py`` in ``config/__init__.py`` zu verschieben. Nicht anzufangen an der normalen Modulsuche vorbei was exotisches zu basteln mit dem niemand rechnet.

Grundsätzlich ist es sowieso eine gute Idee alles in ein Package zu bündeln, damit auf oberster Ebene nur dieser Packagename mit anderen Packages kollidieren kann. Also auch so etwas generisches wie `config` würde ich nicht in diesen ”globalen” Modul/Package-Namensraum stecken.

[YAPD]

Schade. Ich dachte, ich hätte es gut genug erklärt. Und natürlich hast du Recht, dass diese Idee von Perl
kam. Ich habe mich vielleicht zu sehr darauf versteift, dass diese Flexibilität vorhanden sein muss, die mit
Python anscheinend überflüssig ist. Bezgl. der Namen muss ich mich wohl damit abfinden, dass es keine gute Idee ist, Ordner bzw. Packages und Dateien mit dem gleichen Namen zu verwenden. Meine exotische Lösung funktioniert allerdings so , wie ich ich in meinem anderen Post geschrieben habe. Tests haben auch noch keine Fehler ergeben. Ist eine Lösung gleich, falsch, nur weil sie ( in dem Umfang ) nicht nötig ist ?
Oder weil sie in deinem Augen unberechenbar ist ?

[__blackjack__]

@YAPD: Die ist nicht nur in meinen Augen ”unberechenbar”. Da werden auch die üblichen Werkzeuge nicht mit rechnen. Plugins in IDEs die Autovervollständigung anbieten, Linter, Werkzeuge zum prüfen von Typannotationen, zum extrahieren von Dokumentation, Testrunner für Unittests, EXE/App Builder, … Eben alles was die normalen Importe auswertet um Abhängigkeiten verfolgen zu können.