Pfade, Modulnamen und import-Statements
Hallo, ich hab mal eine Verständnisfrage. Gegeben sei ein Verzeichnis . und ein Programm ./keks. Weiterhin sei die Klasse MyClass1 in d/mc1.py und die Klasse MyClass2 in d/mc2.py definierrt. Wenn ich nun in keks die Klasse MyClass2 benutzen möchte, schreibe ich "from d.mc2 import MyClass2". Wnn ich in d/mc1.py dasselbe tun möchte, muss ich dort "from mc2 import MyClass2" schreiben, kann also Code, der "verwandte" Module benutzt, nicht frei verschieben. Ist das so gedacht, oder verpass ich da was? Grüße Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Am 04.05.24 um 13:12 schrieb Marc Haber:
Wnn ich in d/mc1.py dasselbe tun möchte, muss ich dort "from mc2 import MyClass2" schreiben,
Ich vermute, Du musst "from ..mc2 import …" schreiben, da Du das Modul relativ zu mc1 "adressieren" musst. Falls es bei Dir ohne ".." ist irgendwas faul.
kann also Code, der "verwandte" Module benutzt, nicht frei verschieben. Ganz verstehe ich Deine Frage nicht, aber ich sag mal: Ja, das ist so gedacht. Woher sollte python denn sonst wissen, wo es "MyClass2" findet? Und in "keks" muss Du ja auch den "Pfad" zum Modul angeben - warum wollte das in einem Modul anders sein?
-- Regards Hartmut Goebel | Hartmut Goebel |h.goebel@crazy-compilers.com | |www.crazy-compilers.com | compilers which you thought are impossible |
On Sat, May 04, 2024 at 07:22:52PM +0200, Hartmut Goebel wrote:
Am 04.05.24 um 13:12 schrieb Marc Haber:
Wnn ich in d/mc1.py dasselbe tun möchte, muss ich dort "from mc2 import MyClass2" schreiben,
Ich vermute, Du musst "from ..mc2 import …" schreiben, da Du das Modul relativ zu mc1 "adressieren" musst. Falls es bei Dir ohne ".." ist irgendwas faul.
Das funktioniert so wie ich es geschrieben habe. Im etwas konkreteren Fall: [37/5247]mh@swivel:~/git/zg2dns $ grep -E 'class|import' get-root zg2dns/* get-root:from zg2dns.rootdata import DNSRootDataParser zg2dns/query.py:from rootdata import DNSRootDataParser zg2dns/query.py:class Zg2DNSQuery: zg2dns/rootdata.py:class DNSRootDataParser: Sowohl der Code in zg2dns/query-py als auch der code in get-root benutzen die Klasse DNSRootDataParser, und das funktioniert auch: 2 [38/5247]mh@swivel:~/git/zg2dns $ zg2dns/query.py 2024-05-05 10:07:50.360 | DEBUG | __main__:<module>:309 - rootservers.get_ipv4_servers()=['198.41.0.4', '199.9.14.201', '192.33.4.12', '199.7.91.13', '192.203.230.10', '192.5.5.241', '192.112.36.4', '198.97.190.53', '192.36.148.17', '192.58.128.30', '193.0.14.129', '199.7.83.42', '202.12.27.33'] 2024-05-05 10:07:50.360 | DEBUG | __main__:<module>:310 - rootservers.get_ipv6_servers()=['2001:503:ba3e::2:30', '2001:500:200::b', '2001:500:2::c', '2001:500:2d::d', '2001:500:a8::e', '2001:500:2f::f', '2001:500:12::d0d', '2001:500:1::53', '2001:7fe::53', '2001:503:c27::2:30', '2001:7fd::1', '2001:500:9f::42', '2001:dc3::35'] 2024-05-05 10:07:50.360 | DEBUG | __main__:<module>:311 - rootservers.get_all_servers()=['198.41.0.4', '199.9.14.201', '192.33.4.12', '199.7.91.13', '192.203.230.10', '192.5.5.241', '192.112.36.4', '198.97.190.53', '192.36.148.17', '192.58.128.30', '193.0.14.129', '199.7.83.42', '202.12.27.33', '2001:503:ba3e::2:30', '2001:500:200::b', '2001:500:2::c', '2001:500:2d::d', '2001:500:a8::e', '2001:500:2f::f', '2001:500:12::d0d', '2001:500:1::53', '2001:7fe::53', '2001:503:c27::2:30', '2001:7fd::1', '2001:500:9f::42', '2001:dc3::35'] 2024-05-05 10:07:50.361 | DEBUG | __main__:<module>:312 - rootservers()=['198.41.0.4', '199.9.14.201', '192.33.4.12', '199.7.91.13', '192.203.230.10', '192.5.5.241', '192.112.36.4', '198.97.190.53', '192.36.148.17', '192.58.128.30', '193.0.14.129', '199.7.83.42', '202.12.27.33', '2001:503:ba3e::2:30', '2001:500:200::b', '2001:500:2::c', '2001:500:2d::d', '2001:500:a8::e', '2001:500:2f::f', '2001:500:12::d0d', '2001:500:1::53', '2001:7fe::53', '2001:503:c27::2:30', '2001:7fd::1', '2001:500:9f::42', '2001:dc3::35'] [39/5247]mh@swivel:~/git/zg2dns $ ./get-root IPv4 Root Servers: ['198.41.0.4', '199.9.14.201', '192.33.4.12', '199.7.91.13', '192.203.230.10', '192.5.5.241', '192.112.36.4', '198.97.190.53', '192.36.148.17', '192.58.128.30', '193.0.14.129', '199.7.83.42', '202.12.27.33'] IPv6 Root Servers: ['2001:503:ba3e::2:30', '2001:500:200::b', '2001:500:2::c', '2001:500:2d::d', '2001:500:a8::e', '2001:500:2f::f', '2001:500:12::d0d', '2001:500:1::53', '2001:7fe::53', '2001:503:c27::2:30', '2001:7fd::1', '2001:500:9f::42', '2001:dc3::35'] All Root Servers: ['198.41.0.4', '199.9.14.201', '192.33.4.12', '199.7.91.13', '192.203.230.10', '192.5.5.241', '192.112.36.4', '198.97.190.53', '192.36.148.17', '192.58.128.30', '193.0.14.129', '199.7.83.42', '202.12.27.33', '2001:503:ba3e::2:30', '2001:500:200::b', '2001:500:2::c', '2001:500:2d::d', '2001:500:a8::e','2001:500:2f::f', '2001:500:12::d0d', '2001:500:1::53', '2001:7fe::53', '2001:503:c27::2:30', '2001:7fd::1', '2001:500:9f::42', '2001:dc3::35'] All Root Servers: ['198.41.0.4', '199.9.14.201', '192.33.4.12', '199.7.91.13', '192.203.230.10', '192.5.5.241', '192.112.36.4', '198.97.190.53', '192.36.148.17', '192.58.128.30', '193.0.14.129', '199.7.83.42', '202.12.27.33', '2001:503:ba3e::2:30', '2001:500:200::b', '2001:500:2::c', '2001:500:2d::d', '2001:500:a8::e','2001:500:2f::f', '2001:500:12::d0d', '2001:500:1::53', '2001:7fe::53', '2001:503:c27::2:30', '2001:7fd::1', '2001:500:9f::42', '2001:dc3::35'] [40/5247]mh@swivel:~/git/zg2dns $ Die Notation ..irgendwas ist also nicht notwendig.
kann also Code, der "verwandte" Module benutzt, nicht frei verschieben. Ganz verstehe ich Deine Frage nicht, aber ich sag mal: Ja, das ist so gedacht. Woher sollte python denn sonst wissen, wo es "MyClass2" findet? Und in "keks" muss Du ja auch den "Pfad" zum Modul angeben - warum wollte das in einem Modul anders sein?
Ich finde es wenig schön dass man abhängig vom Ort der Nutzung unterschiedliche Import-Statements schreiben muss, aber wenn das so ist kann ich damit leben. Ich hatte das Verhalten halt nicht für pythonisch gehalten. In dnspython ist das auch nicht so geschrieben, z.B. steht in /usr/lib/python3/dist-packages/dns/resolver.py immer das Predix dns in den Imports dabei. Das funktioniert vermutlich, weil /usr/lib/python3/dist-packages im Pythonpath steht. Wäre ich dnspython-Entwickler, hätte ich ja meine workingcopy von mir aus unter ~/git/dnspython ausgecheckt, und wenn ich irgendwas ausprobiere, würde das "import dns.query" in ~/git/dnspython/dns/resolver.py ja das dns/query.py aus dem Pythonpath anziehen und nicht das aus meiner Workingcopy, weil ich ja sicher auch die Releaseversion der Library installiert hätte. Wir arbeiten Modulentwicker in so einer Situation? Grüße Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Marc Haber wrote:
[37/5247]mh@swivel:~/git/zg2dns $ grep -E 'class|import' get-root zg2dns/* get-root:from zg2dns.rootdata import DNSRootDataParser zg2dns/query.py:from rootdata import DNSRootDataParser zg2dns/query.py:class Zg2DNSQuery: zg2dns/rootdata.py:class DNSRootDataParser:
Versuche mal "zg2dns.query" zu importieren: | Traceback (most recent call last): | File "/tmp/t/test", line 3, in <module> | import zg2dns.query | File "/tmp/t/zg2dns/query.py", line 1, in <module> | from rootdata import DNSRootDataParser | ModuleNotFoundError: No module named 'rootdata'
Ich finde es wenig schön dass man abhängig vom Ort der Nutzung unterschiedliche Import-Statements schreiben muss, aber wenn das so ist kann ich damit leben. Ich hatte das Verhalten halt nicht für pythonisch gehalten.
Dein Fehler ist ein komplett anderer. Der Python-Interpreter fügt das Verzeichnis, in dem das aktuelle Script liegt, dem Suchpfad hinzu. Rufst du "get-root" auf, dann ist es ".". Damit findet "import zg2dns.rootdata" auch "zg2dns/rootdata.py". Rufst du aber "zg2dns/query.py" direkt auf, dann ist auf einmal das Verzeichnis "zg2dns" im Suchpfad. Also referenziert "import rootdata" auf einmal was anderes.
Wäre ich dnspython-Entwickler, hätte ich ja meine workingcopy von mir aus unter ~/git/dnspython ausgecheckt, und wenn ich irgendwas ausprobiere, würde das "import dns.query" in ~/git/dnspython/dns/resolver.py ja das dns/query.py aus dem Pythonpath anziehen und nicht das aus meiner Workingcopy, weil ich ja sicher auch die Releaseversion der Library installiert hätte.
Dafür gibt es "pip install -e ." z.B. Damit macht man das aktuelle Projekt im globalen Suchpfad des benutzten Interpreters verfügbar.
Wir arbeiten Modulentwicker in so einer Situation?
Module werden nicht als Scripte direkt aufgerufen, sind also auch nie ausführbar. Statt dessen werden sie mittels "python3 -m" aufgerufen. Im nächsten Schritt kommen dann Entry-Points, aus denen dann Scripte entstehen, welche in $prefix/bin landen. Bastian
On Sun, May 05, 2024 at 10:32:28AM -0000, Bastian Blank wrote:
Marc Haber wrote:
[37/5247]mh@swivel:~/git/zg2dns $ grep -E 'class|import' get-root zg2dns/* get-root:from zg2dns.rootdata import DNSRootDataParser zg2dns/query.py:from rootdata import DNSRootDataParser zg2dns/query.py:class Zg2DNSQuery: zg2dns/rootdata.py:class DNSRootDataParser:
Versuche mal "zg2dns.query" zu importieren
Wo?
Der Python-Interpreter fügt das Verzeichnis, in dem das aktuelle Script liegt, dem Suchpfad hinzu.
Rufst du "get-root" auf, dann ist es ".". Damit findet "import zg2dns.rootdata" auch "zg2dns/rootdata.py".
Rufst du aber "zg2dns/query.py" direkt auf, dann ist auf einmal das Verzeichnis "zg2dns" im Suchpfad. Also referenziert "import rootdata" auf einmal was anderes.
Also muss ich abhängig von dem Ort wo mein Skript liegt unterschiedliche import-Statements benutzen, das finde ich mindestens unschön. Aber jetzt wo ich es weiß kann ich aes natürlich machen.
Dafür gibt es "pip install -e ." z.B. Damit macht man das aktuelle Projekt im globalen Suchpfad des benutzten Interpreters verfügbar.
Aber hoffentlich nur im Environment einer Subshell? Oder ist das persistentes Herumfummeln im System? Wenn ja, wo?
Wir arbeiten Modulentwicker in so einer Situation?
Module werden nicht als Scripte direkt aufgerufen, sind also auch nie ausführbar. Statt dessen werden sie mittels "python3 -m" aufgerufen.
Das Python Tutorial Kapitel 6.1.1 "Executing modules as scripts" stelt das als ganz praktisches Feature dar. Grüße Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Am 10.05.24 um 11:37 schrieb Marc Haber:
Dafür gibt es "pip install -e ." z.B. Damit macht man das aktuelle Projekt im globalen Suchpfad des benutzten Interpreters verfügbar. Aber hoffentlich nur im Environment einer Subshell? Oder ist das persistentes Herumfummeln im System? Wenn ja, wo?
pip install installiert per default nach /usr/lib/pythonX.YZ/site-packages. Debian lässt das aber gar nicht mehr zu. Wenn ein virtual environment aktiv ist, wird nach <venv>/lib/pythonX.YZ/site-packages installliert. Dito bei nicht-aktivem vend und "<venv>/bin/pip install". Option --user installiert nach $HOME/.local/lib/pythonX.YZ/site-packages. pip list zeigt Dir, was wo installiert ist. (Bei aktivem venv aber im venv und nicht im System.) -- Regards Hartmut Goebel | Hartmut Goebel |h.goebel@crazy-compilers.com | |www.crazy-compilers.com | compilers which you thought are impossible |
On 2024-05-04 11:12, Marc Haber <mh+python-de@zugschlus.de> wrote:
ich hab mal eine Verständnisfrage.
Gegeben sei ein Verzeichnis . und ein Programm ./keks. Weiterhin sei die Klasse MyClass1 in d/mc1.py und die Klasse MyClass2 in d/mc2.py definierrt.
Wenn ich nun in keks die Klasse MyClass2 benutzen möchte, schreibe ich "from d.mc2 import MyClass2". Wnn ich in d/mc1.py dasselbe tun möchte, muss ich dort "from mc2 import MyClass2" schreiben,
Nein, das funktioniert nicht: #v+ % ./keks Traceback (most recent call last): File "/home/hjp/tmp/marc/./keks", line 3, in <module> from d.mc1 import MyClass1 File "/home/hjp/tmp/marc/d/mc1.py", line 1, in <module> from mc2 import MyClass2 ModuleNotFoundError: No module named 'mc2' #v- Es muss #v+ from d.mc2 import MyClass2 #v- heißen. Ob Du das Modul von keks oder von einem anderen Modul aus importierst, macht keinen Unterschied.
kann also Code, der "verwandte" Module benutzt, nicht frei verschieben.
Ist das so gedacht, oder verpass ich da was?
Wie Hartmut schon geschrieben hat, kannst Du relative Imports verwendenm, hier also #v+ from .mc2 import MyClass2 #v- Ob das für Deinen Code sinnvoll ist, musst du selbst entscheiden. hp
On Sun, May 05, 2024 at 02:26:02AM +0200, Peter J. Holzer wrote:
On 2024-05-04 11:12, Marc Haber <mh+python-de@zugschlus.de> wrote:
ich hab mal eine Verständnisfrage.
Gegeben sei ein Verzeichnis . und ein Programm ./keks. Weiterhin sei die Klasse MyClass1 in d/mc1.py und die Klasse MyClass2 in d/mc2.py definierrt.
Wenn ich nun in keks die Klasse MyClass2 benutzen möchte, schreibe ich "from d.mc2 import MyClass2". Wnn ich in d/mc1.py dasselbe tun möchte, muss ich dort "from mc2 import MyClass2" schreiben,
Nein, das funktioniert nicht:
#v+ % ./keks Traceback (most recent call last): File "/home/hjp/tmp/marc/./keks", line 3, in <module> from d.mc1 import MyClass1 File "/home/hjp/tmp/marc/d/mc1.py", line 1, in <module> from mc2 import MyClass2 ModuleNotFoundError: No module named 'mc2' #v-
Mein mc1.py hat eingebauten testcode: #v+ if __name__ == "__main__": zdns = Zg2DNSQuery(timeout=2, debug=True) rootservers = DNSRootDataParser() logger.debug(f"{rootservers.get_ipv4_servers()=}") #v- verhält sich der vielleicht anders als wenn man nur das Modul importiert? Das wäre dann ja noch viel schlimmer ;-) Grüße Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
On 2024-05-05 08:25, Marc Haber <mh+python-de@zugschlus.de> wrote:
On Sun, May 05, 2024 at 02:26:02AM +0200, Peter J. Holzer wrote:
On 2024-05-04 11:12, Marc Haber <mh+python-de@zugschlus.de> wrote:
ich hab mal eine Verständnisfrage.
Gegeben sei ein Verzeichnis . und ein Programm ./keks. Weiterhin sei die Klasse MyClass1 in d/mc1.py und die Klasse MyClass2 in d/mc2.py definierrt.
Wenn ich nun in keks die Klasse MyClass2 benutzen möchte, schreibe ich "from d.mc2 import MyClass2". Wnn ich in d/mc1.py dasselbe tun möchte, muss ich dort "from mc2 import MyClass2" schreiben,
Nein, das funktioniert nicht:
#v+ % ./keks Traceback (most recent call last): File "/home/hjp/tmp/marc/./keks", line 3, in <module> from d.mc1 import MyClass1 File "/home/hjp/tmp/marc/d/mc1.py", line 1, in <module> from mc2 import MyClass2 ModuleNotFoundError: No module named 'mc2' #v-
Mein mc1.py hat eingebauten testcode:
#v+ if __name__ == "__main__": zdns = Zg2DNSQuery(timeout=2, debug=True)
rootservers = DNSRootDataParser() logger.debug(f"{rootservers.get_ipv4_servers()=}") #v-
Ah, dachte ich mir, dass da eine wichtige Information fehlt ;-).
verhält sich der vielleicht anders als wenn man nur das Modul importiert? Das wäre dann ja noch viel schlimmer ;-)
Wenn Du ein Script aufrufst, wird das Directory des Scripts in sys.path eingefügt. Dadurch wird dann bei einem "import m" u.a. auch nach "full_path_to_script_dir/m.py" gesucht und damit funktioniert der Import. Zum Testen von komplexeren Packages ist das aber wenig hilfreich, weil im echten Einsatz natürlich nicht irgendwelche Subdirectorys der Package-Hierarchie im Suchpfad stehen und man, wenn man ein Modul aus einem Package direkt aufruft, die Package-Hierarchie verliert und damit relative Imports nicht funktionieren: #v+ % python3 d/mc1.py __main__ ['/home/hjp/tmp/marc/d', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/home/hjp/.local/lib/python3.10/site-packages', '/usr/local/lib/python3.10/dist-packages', '/usr/lib/python3/dist-packages'] Traceback (most recent call last): File "/home/hjp/tmp/marc/d/mc1.py", line 4, in <module> from .mc2 import MyClass2 ImportError: attempted relative import with no known parent package #v- Unter anderem auch aus diesem Grund schreibe ich Test-Code immer in eigene Files. hp
On Sun, May 05, 2024 at 12:38:18PM +0200, Peter J. Holzer wrote:
On 2024-05-05 08:25, Marc Haber <mh+python-de@zugschlus.de> wrote:
On Sun, May 05, 2024 at 02:26:02AM +0200, Peter J. Holzer wrote:
On 2024-05-04 11:12, Marc Haber <mh+python-de@zugschlus.de> wrote:
ich hab mal eine Verständnisfrage.
Gegeben sei ein Verzeichnis . und ein Programm ./keks. Weiterhin sei die Klasse MyClass1 in d/mc1.py und die Klasse MyClass2 in d/mc2.py definierrt.
Wenn ich nun in keks die Klasse MyClass2 benutzen möchte, schreibe ich "from d.mc2 import MyClass2". Wnn ich in d/mc1.py dasselbe tun möchte, muss ich dort "from mc2 import MyClass2" schreiben,
Nein, das funktioniert nicht:
#v+ % ./keks Traceback (most recent call last): File "/home/hjp/tmp/marc/./keks", line 3, in <module> from d.mc1 import MyClass1 File "/home/hjp/tmp/marc/d/mc1.py", line 1, in <module> from mc2 import MyClass2 ModuleNotFoundError: No module named 'mc2' #v-
Mein mc1.py hat eingebauten testcode:
#v+ if __name__ == "__main__": zdns = Zg2DNSQuery(timeout=2, debug=True)
rootservers = DNSRootDataParser() logger.debug(f"{rootservers.get_ipv4_servers()=}") #v-
Ah, dachte ich mir, dass da eine wichtige Information fehlt ;-).
Welche? Dass ich den Empfehlungen des Python Tutorials, Kapitel 6.1.1 "Executing modules as scripts" gefolgt bin? War das falsch?
Unter anderem auch aus diesem Grund schreibe ich Test-Code immer in eigene Files.
So werde ich das dann jetzt wohl auch halten. Schade. Grüße Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
On 2024-05-10 09:39, Marc Haber <mh+python-de@zugschlus.de> wrote:
On Sun, May 05, 2024 at 12:38:18PM +0200, Peter J. Holzer wrote:
Ah, dachte ich mir, dass da eine wichtige Information fehlt ;-).
Welche?
Die Information, dass Du das gleiche Python-File einmal mittels import und einmal als Script ausführst. Das sind unterschiedliche Mechanismen.
Dass ich den Empfehlungen des Python Tutorials, Kapitel 6.1.1 "Executing modules as scripts" gefolgt bin? War das falsch?
Das funktioniert in einigen einfachen Fällen (insbesondere, wenn das Modul keine weiteren Imports (außer Standard-Modulen) hat oder wenn die alle direkt im Suchpfad liegen. Wenn man das mit einem Submodul eines Packages probiert, muss man sich das Environment entsprechend herrichten (z.B. indem man $PYTHONPATH passend setzt). Keine große Hexerei, wenn man es weiß, aber selbst dann vergisst man gerne darauf (ich zumindest). Ich würde daher davon abraten. hp
Am 04.05.24 um 13:12 schrieb Marc Haber:
ich hab mal eine Verständnisfrage.
Gegeben sei ein Verzeichnis . und ein Programm ./keks. Weiterhin sei die Klasse MyClass1 in d/mc1.py und die Klasse MyClass2 in d/mc2.py definierrt.
Wenn ich nun in keks die Klasse MyClass2 benutzen möchte, schreibe ich "from d.mc2 import MyClass2". Wnn ich in d/mc1.py dasselbe tun möchte, muss ich dort "from mc2 import MyClass2" schreiben, kann also Code, der "verwandte" Module benutzt, nicht frei verschieben.
Ist das so gedacht, oder verpass ich da was?
Bei Pfadproblemen verwende ich sys.path.append( Hermann der das #include ../ich.h für gemeinsames vermisst. -- <http://www.hermann-riemann.de>
On Sun, May 05, 2024 at 12:02:34PM +0200, Hermann Riemann wrote:
Bei Pfadproblemen verwende ich sys.path.append(
In Klassen- und Moduldefinitionen und importen? Echt jetzt? Oder hast Du nur die Frage nicht verstanden? Grüße Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Am 04.05.24 um 13:12 schrieb Marc Haber:
ich hab mal eine Verständnisfrage.
Gegeben sei ein Verzeichnis . und ein Programm ./keks. Weiterhin sei die Klasse MyClass1 in d/mc1.py und die Klasse MyClass2 in d/mc2.py definierrt.
Wenn ich nun in keks die Klasse MyClass2 benutzen möchte, schreibe ich "from d.mc2 import MyClass2". Wenn ich in d/mc1.py dasselbe tun möchte, muss ich dort "from mc2 import MyClass2" schreiben, kann also Code, der "verwandte" Module benutzt, nicht frei verschieben.
Ist das so gedacht, oder verpass ich da was?
Ein wenig lässt sich mit sys.path.append erreichen. Ich benutze das für meine Hilfsprogramme, die von mehreren Programme verwendet werden. -- <http://www.hermann-riemann.de>
participants (5)
-
Bastian Blank -
Hartmut Goebel -
Hermann Riemann -
Marc Haber -
Peter J. Holzer