[Python-de] BeautifulSoup contents Listen error

Andrew Smart subscriptions at smart-knowhow.de
Do Jun 5 14:11:37 UTC 2008


> -----Ursprüngliche Nachricht-----
> Von: python-de-bounces at python.net 
> [mailto:python-de-bounces at 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