-----Ursprüngliche Nachricht----- Von: python-de-bounces@python.net [mailto:python-de-bounces@python.net] Im Auftrag von Stefan Schwarzer Gesendet: Mittwoch, 4. Juni 2008 20:48 An: Die Deutsche Python Mailingliste Betreff: Re: [Python-de] BeautifulSoup contents Listen error
Hallo Alexander,
On 2008-06-02 16:01, A. Nigl wrote: was ist, wenn Beautiful Soup die Datei ohne zu "meckern" parst, aber nicht das dabei rauskommt, was gemeint ist? Wenn du die Dateien so nimmst, wie sie kommen, kann es passieren, dass sie zwar gelesen werden aber falsche Daten in deiner Anwendung ankommen. (Zum Vergleich: Wenn jemand aus "Geben Sie mir die Hund" fehlertolerant "Geben Sie mir die Hand" macht, könnte er sich irren; vielleicht war "Geben Sie mir den Hund" gemeint.) Wenn du fehlerhaftes XML zurückweist, reduzierst du die Wahrscheinlichkeit solcher "Missverständnisse" schonmal ein Stück weit.
Ich kann Alexander schon verstehen. Wenn er keinen Einfluß auf die Qualität hat wird alles "ich will aber nur 100% einwandfreies XML" nur dazu führen das seine Software den gewünschten Nutzen nicht bringen kann. Punktum. Ich hab in meinem Berufsleben solche Fälle schon zigmal gehabt. Hersteller die sich nicht an Specs halten, API's die unvollständig implementiert sind etc. Sich da auf den Standpunkt zu stellen: "damit arbeite ich nicht" hat nur zur Folge das nix passiert. Da ist dann Pragmatismus und nicht Ideologie angesagt. Ob man nun hergehen sollte und eine Bibliothek verwenden sollte, die einen eigenständigen, nicht kontrollierbaren Fehler-Korrekturmechanismus verwendet, sei mal dahingestellt. Für mich wäre hier interessant zu prüfen welche Form von Fehlern vorkommen: sind das eher technische Fehler wie "nicht geschlossene XML-Tags", sind es Syntaxfehler (nicht codierte Sonderzeichen, nicht geschlossene Strings etc) oder sind es eher semantische Fehler (Tags die es lt DTD geben muss sind nicht angegeben). Je nach Typ kann es in BeautifulSoup zu ganz unterschiedlichen gutgemeinten Fehlerkorrekturen kommen - gewollte und ungewollte. Und dann geht Alexander durchaus das Risiko "Hand" oder "Hund" ein. Ich würde da noch einen anderen Gedankengang vorschlagen: je nach Fehlerart könnte man auch ein XML-Lieferant-bezogenes Korrekturscript schreiben das korrektes XML herstellt. Die eigentliche Importschnittstelle erwartet dann 100% perfektes XML. Das trennt Fehlerbehandlung von der eigentlichen Schnittstelle, und hat zudem die Option spezifische Fehlerbehandlungen zuzulassen. Sollte nämlich mal einer der "guten" Lieferanten plötzlich ebenfalls mieses XML liefern dann würde man das mit der Konstruktion mitbekommen, während man sich bei einem BeautifulSoup-Ansatz fälschlicherweise in Sicherheit wiegt. Man minimiert somit die mögliche Fehlerquote durch dedizierte Fehlerbehandlung, und hat einen automatischen Mechanismus für die Qualitätssicherung. Setzt voraus das die Lieferanten konsequent bei ihren Fehlern bleiben, d.h. das es sich lohnt die Fehlerbehandlung gezielt zu implementieren. Wenn man einfach nur aus X Quellen Mist in varierender Qualität geliefert bekommt, dann kann man nur Duftwasser drüberkippen (BeatifulSoup) und hoffen das hinten irgendwas vernünftiges rauskommt. Just my 2cents, Andrew