Hallo zusammen,
ich habe gerade folgende Problemstellung.
Ich habe eine library importiert, die dem einlesen von Daten in einem spezifischen Format dient. Das Problem ist nun, dass beim Einlesen eines recht großen Datensatzes extrem viele Warnings ausgegeben werden. Die Ausgabe bremst mein Programm ziemlich aus. Das ganze dauert ca. 3 min wobei der Rest des Programmes noch ca 18 sec benötigt.
Gibt es prinzipiell die Möglichkeit diese Warnings zu unterdrücken? Bzw. gibt es eine Möglichkeit den Output der in einer Funktion/Methode erzeugt wird zu unterdrücken?
Meine Suche war bisher leider erfoglos, da ich irgendwie auch keinen rechten Plan habe wonach ich suchen muss.
Warnings unterdrücken
Wird wohl in der Doku der Lib stehen. Grundsätzlich kannst du aber stderr und stdout umlenken(wenn die Funktion dahin loggt). Guck dir mal sys.stdout und sys.stderr an. Die kannst du einfach überschreiben.
Code: Alles auswählen
import sys
class NullStream:
def write(self, bytes): pass
print "Test"
sys.stdout = NullStream()
print "Test"
Zuletzt geändert von Darii am Mittwoch 12. November 2008, 09:52, insgesamt 1-mal geändert.
Du sagst nicht welche Bibliothek oder was für Warnungen. Ich glaube daher, dass ist bibliotheksspezifisch und nicht Python-spezifisch. Aber warum lenkst du die Ausgabe (stdout oder stderr oder beides) nicht in eine Datei oder nach /dev/null (unter Windows ist das glaube ich einfach nur NUL) um? Das ist in der Regel schneller, als wie es eine Konsole anzeigen kann.
Stefan
Stefan
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Das ``warnings``-Modul bietet die Möglichkeit die darüber ausgegebenen Warnungen zu unterdrücken.
Besser noch: Es so machen, dass gar keine Warnings angezeigt werden müssen
Besser noch: Es so machen, dass gar keine Warnings angezeigt werden müssen

My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Die Warnings sind bibliotheksspezifisch.
Das Problem ist, dass ich nicht den Gesamten stdout ausblenden will, sondern nur das was eine einzelne Funktion mir auswirft. Mit /dev/null oder ähnlichem ist mir also leider nicht geholfen.
Mit dem Warningmodul haben wir mittlerweile auch rumprobiert. Prinzipiell funktioniert es. Aber leider nicht mit unserer Lib. Aber auf jeden Fall schonmal ein dickes Danke für den Hinweis. Ich kann das in einem anderen Projekt gut brauchen und da funktioniert es.
Danach haben wir dann festgestellt, dass das ganze eine C-API hat und das ganze evtl keine "python-warnings" sind (ich kenne mich da nicht so aus)?
Das überscheiben von sys.stdout bzw sys.stderr hat so leider nicht funktioniert.
Hat noch jemand eine Idee?
Das Problem ist, dass ich nicht den Gesamten stdout ausblenden will, sondern nur das was eine einzelne Funktion mir auswirft. Mit /dev/null oder ähnlichem ist mir also leider nicht geholfen.
Mit dem Warningmodul haben wir mittlerweile auch rumprobiert. Prinzipiell funktioniert es. Aber leider nicht mit unserer Lib. Aber auf jeden Fall schonmal ein dickes Danke für den Hinweis. Ich kann das in einem anderen Projekt gut brauchen und da funktioniert es.
Danach haben wir dann festgestellt, dass das ganze eine C-API hat und das ganze evtl keine "python-warnings" sind (ich kenne mich da nicht so aus)?
Das überscheiben von sys.stdout bzw sys.stderr hat so leider nicht funktioniert.
Hat noch jemand eine Idee?
Ja, kontaktiere die Entwickler. Auch wenn es eine kommerzielle Library ist. Wenn es Probleme mit dem Parsing von Dateien gibt, so sind die Warnings ja in der Regel sinnvoll. Und wenn der Parser ein Update braucht, so ist es womöglich besser, das umzusetzen, als ggf. schlecht geparste Daten zu akzeptieren.
Gruß,
Christian
Gruß,
Christian
Die Warning sind schon plausibel und machen Sinn!
In dem File (GRIB-Format für den Fall, dass es jemand kennt) ist eine Zeitreihe von Messdaten. Die Zeitreihe hat allerdings Lücken. Und vor den Lücken warnt die Library. Das Problem ist, dass es extrem viele Daten und auch recht viele Lücken sind.
Wir sind uns der Lücken bewusst und fangen das dann auch im Hauptprogramm ab, so dass es nicht auf die Nase fliegt.
Nur machen die Warnings das ganze so dermaßen langsam, dass uns die ganze schöne Performance flöten geht
Wahrscheinlich werde ich mich wirklich an die Hersteller wenden müssen. Das Problem ist nur, dass es sich da um eine recht träge Behörde handelt, die in der Regel auf solche Dinge nur seeeeeehr langsam reagiert.
Also wenn noch jemand einen Kniff parat hat wäre ich sehr dankbar!
Aber auf jeden Fall mal vielen Dank für die Lösungsansätze.
In dem File (GRIB-Format für den Fall, dass es jemand kennt) ist eine Zeitreihe von Messdaten. Die Zeitreihe hat allerdings Lücken. Und vor den Lücken warnt die Library. Das Problem ist, dass es extrem viele Daten und auch recht viele Lücken sind.
Wir sind uns der Lücken bewusst und fangen das dann auch im Hauptprogramm ab, so dass es nicht auf die Nase fliegt.
Nur machen die Warnings das ganze so dermaßen langsam, dass uns die ganze schöne Performance flöten geht


Wahrscheinlich werde ich mich wirklich an die Hersteller wenden müssen. Das Problem ist nur, dass es sich da um eine recht träge Behörde handelt, die in der Regel auf solche Dinge nur seeeeeehr langsam reagiert.
Also wenn noch jemand einen Kniff parat hat wäre ich sehr dankbar!
Aber auf jeden Fall mal vielen Dank für die Lösungsansätze.
Na ja, bei OpenSource libraries gibt es BugTracker. Bei Behörden hilft meist gewieftes Telefonieren
: Wenn man die Entwickler dort bei der Ehre packt, kommt man manchmal auch weiter ... Vielleicht sagt man Dir dort aber auch, wie man das abstellen kann, falls es schon implementiert ist.
Viel Glück!

Viel Glück!
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
Je nachdem wie deine externe lib aufgebaut ist könntest du einen filternden Wrapper bauen. Aber wenn die Warnungen berechtigt sind, solltest du das am besten sein lassen
Du könntest natürlich auch die Warnungen in eine Log-Datei umleiten, so wären sie zumindest nicht verloren.

Du könntest natürlich auch die Warnungen in eine Log-Datei umleiten, so wären sie zumindest nicht verloren.