import xml.etree funktioniert nicht

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.
Antworten
niederrheiner
User
Beiträge: 30
Registriert: Montag 7. Januar 2013, 11:52

Hallo an Alle,
ich habe folgendes Script:

Code: Alles auswählen

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
#  xml.py
#  

import xml.dom.minidom as dom
import xml.etree.ElementTree as etree

tree = etree.parse('/home/guenter/xt310/2013-11-27_12-45-02_4_58.tcx')
root = etree.getroot()
print('root: ',root)
print('root.attrib: ',root.attrib)
print('root[4]: ',root[4])
print('root[4].attrib: ',root[4].attrib)

Das Programm wird aber mit folgender Fehlermeldung beendet:

Code: Alles auswählen

Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1521, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "xml.py", line 26, in <module>
    import xml.dom.minidom as dom
  File "/home/guenter/Projekte/python/vhs/xml.py", line 26, in <module>
    import xml.dom.minidom as dom
ImportError: No module named 'xml.dom'; xml is not a package

Mein System ist ein Archlinux_x64 und Python3 ist installiert.
An welcher Schraube muss ich drehen, damit der Import der Module klappt?

Bis dann ...
MfG
Günter
Benutzeravatar
/me
User
Beiträge: 3554
Registriert: Donnerstag 25. Juni 2009, 14:40
Wohnort: Bonn

niederrheiner hat geschrieben:An welcher Schraube muss ich drehen, damit der Import der Module klappt?
Du hast dein Skript genau so genannt wie das Package aus der Standardbibliothek. Beim Import wird jetzt versucht dein Skript zu importieren, da es in der Suchreihenfolge eher gefunden wird als das Package. Benenne dein Skript um.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Nenne deine eigene Datei *nicht* wie das Modul, was du verwenden möchtest. Dein eigenes Modul sollte also nicht `xml.py` heißen. Denn sonst wird ungewollterweise auch nur dein Modul importiert, wodurch es zu dieser Fehlermeldung kommt.
niederrheiner
User
Beiträge: 30
Registriert: Montag 7. Januar 2013, 11:52

Danke an Euch Beiden.
Es hat geholfen. Ist eigentlich logisch, habe aber bei der Namensvergabe nicht sonderlich nachgedacht. :(

Bis dann ...
MfG
Günter
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

niederrheiner hat geschrieben:Es hat geholfen. Ist eigentlich logisch, habe aber bei der Namensvergabe nicht sonderlich nachgedacht. :(
Naja, das ist eher ne Festlegung, die man mal getroffen hat. Genau so gut hätte es auch sein können, dass das aktuelle Verzeichnis als allerletztes in der Suchreihenfolge für Modulimporte steht. Dann hätte dein Versuch auch Erfolg gehabt. ;)
BlackJack

@snafu: Ich denke nicht dass das eine willkürliche Festlegung war. Denn dann könnte eine neue Python-Version oder das Installieren *irgendeines* Python-Moduls oder -Pakets potentiell jede in Python geschriebene Anwendung auf dem System „kaputt machen” wenn dort ein gleichnamiges Modul besteht. In so fern ist es schon logisch anzunehmen das lokal zuerst geschaut wird. Ist bei Namen in Funktionen ja letztendlich aus den gleichen Gründen genau so.
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

Nun snafu sagte ja nicht, dass sie "willkuerlich" ist, sondern dass die Reihenfolge eben einfach festgelegt wurde.

Vom Logischen Standpunkt sehe ich jetzt auch keine Gruende warum sie zwingend so sein muss wie sie ist.
Dass man sich andersherum mehr Probleme einhandelt ist ein anderes Paar Schuhe, aber man koennte damit eben sicherstellen, dass ein Kernmodul nicht ueberschrieben wird.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Auf Python bezogen ist es durchaus konsistent, dass man ähnlich zum Schema der schon genannten Namenauflösung vorgeht und somit auch für Module alles, was lokal vorhanden ist, bevorzugt behandelt. Bezogen auf die Kommandozeile (bzw unixoide Shells) ist es aber schon wieder etwas anderes: Wenn ich da ein Programm aufrufen will, welches lokal (also: im aktuellen Verzeichnis) vorliegt, dann muss ich dies explizit angeben mittels ``./mein_programm``. Bei Python ist hingegen kein ``import .mein_modul`` nötig. Das ist ja schon ein Unterschied.

Keine Frage: Man kann hier gute Gründe haben, warum man einmal so und einmal so vorgeht. Ich meinte nur, dass es sich nicht jedem Anwender gleich erschließen muss (nennen wir es "logisch" / "intuitiv" oder sonstwie), wieso Python sich bei Importen eben genau auf diese Weise verhält. Es könnte rein theoretisch auch umgekehrt sein. Mehr wollte ich damit nicht ausdrücken.
Antworten