GTK Errors/Warnings beim importieren von pynotify

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
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Beim Importieren von Pynotify erhalte ich diese lästigen GTK-Warnungen:

Code: Alles auswählen

** (process:25512): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'
** (process:25512): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
** (process:25512): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
Wie kann ich die unterdrücken/verhindern?

Stderr/Stdout kurzzeitig umzuleiten geht nicht:

Code: Alles auswählen

>>> import sys
>>> from io import BytesIO
>>> sys.stderr = BytesIO()
>>> sys.stdout = BytesIO()
>>> print 's'
>>> import pynotify

** (process:25512): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:25512): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:25512): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
Und über das `warnings` Modul geht es auch nicht (das habe ich im Internet dazu gefunden):

Code: Alles auswählen

with warnings.catch_warnings():
    warnings.simplefilter('error')
    import pynotify
Irgendeine Idee wie ich diese Meldungen unterdrücken/verhindern kann?

Auch auf StackOverflow
the more they change the more they stay the same
BlackJack

@Dav1d: Das geht wahrscheinlich gar nicht, denn das wird weder von Python noch von dem Erweiterungsmodul für Python ausgegeben sondern direkt von der C-Bibliothek die angebunden wird.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Du könntest höchstens mal `stderr` des gesamten Prozesses (also auf Shell-Ebene) umleiten. Aber ich würd es einfach so lassen, wie's ist. Bei GTK-basierten Programmen kriegt man doch eigentlich andauernd irgendwelche komischen Warnings ausgespuckt. ^^

Vielleicht lässt sich auch über eine bestimmte Umgebungsvariable die Gesprächigkeit der GLib (oder wer auch immer sich da meldet) konfigurieren? Keine Ahnung...
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

BlackJack hat geschrieben:@Dav1d: Das geht wahrscheinlich gar nicht, denn das wird weder von Python noch von dem Erweiterungsmodul für Python ausgegeben sondern direkt von der C-Bibliothek die angebunden wird.
Das habe ich befürchtet.

@snafu, gute Idee, mal schauen evt. finde ich etwas dazu.
the more they change the more they stay the same
lunar

@Dav1d: Du kannst die Standardausgabe und den Standardfehlerstrom direkt über ihre Dateideskriptoren umleiten, um diese Ausgabe zu unterdrücken. Dann allerdings hast Du wirklich gar keine Ausgabe mehr, sprich auch keine Tracebacks und andere nützliche Meldungen.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

@lunar, das hört sich schonmal gut an. Ich kann doch Stderr nur kurzfristig umleiten (nach dem import von pynotify wieder zurücksetzen). Wie würde ich denn, überhaupt stderr umleiten, es wird ja anscheinend nicht nach sys.stderr geschrieben.
the more they change the more they stay the same
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

Du hast die Antworten glaube ich falsch verstanden: die Bibliothek schreibt selbst auf stderr, mit Python hast du gar keine Chance in deinem Programm an die Ausgabe zu kommen und diese zu unterdrücken. Alle Vorschläge beziehen sich darauf, dass du in deiner Shell die Ausgabe einfach verwirfst. Wie aber schon angemerkt wurde, hastd du dann gar keine Fehlerausgabe mehr.

Du könntest noch ein weiteres Script schreiben, welches dein Programm mittels subprocess aufruft. Die darin gemacht Ausgaben kannst du dann filtern. Ich würde aber die Finger von so einer "Lösung" lassen und mit den Ausgaben leben. Die sind ja nicht sinnlos da. Hier würde ich noch die Idee von snafu mit der möglichen Konfigurierbarkeit über Umgebungsvariablen nachgehen.
Das Leben ist wie ein Tennisball.
lunar

@Dav1d: Stimmt, es wird nicht nach "sys.stderr" geschrieben. Deswegen sollst Du ja auch die Dateideskriptoren selbst umleiten :) Dazu ein Beispiel :)

Hintergrund: Hinter den Python-spezifischen Dateiobjekten "sys.stdin", "sys.stdout" und "sys.stderr" stehen die Dateideskriptoren 0, 1 und 2, die diese Datenströme auf Ebene des Betriebssystems identifizieren. Diese Deskriptoren kannst Du mithilfe der Funktion aus "os" direkt umleiten, so dass fast jede Ausgabe innerhalb Deines Prozesses, sei es aus Python oder aus C heraus, unterdrückt wird, eben weil die Umleitung auf Ebene des Systems stattfinden.

Allerdings würde ich Dir ebenso wie EyDu davon abraten, derartige Warnungen pauschal zu unterdrücken. Dein Programm sollte mindestens eine Kommandozeilenoption anbieten, mit der sich die Umleitung verhindern lässt.

@EyDu: Man kann die Ausgabe auch direkt aus Python heraus umleiten, indem man die Dateideskriptoren direkt manipuliert. Dann schreibt auch C-Coe nicht mehr auf das Terminal. "subprocess" braucht es nicht.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Vielen Dank, das funktioniert perfekt :).

Dank im Python-Forum und Reputation auf SO.
the more they change the more they stay the same
Antworten