GNOME Bugzilla – Bug 323786
unwanted log handler
Last modified: 2006-05-08 16:01:02 UTC
From gtkmodule.c:init_gtk(): g_log_set_handler("Gtk", G_LOG_LEVEL_CRITICAL|G_LOG_LEVEL_WARNING, _pygtk_log_func, NULL); I'm embedding python in Epiphany, and this causes my default log handler (which is used for debugging) to not be called for gtk warnings. Pygtk shouldn't install this handler.
I don't see why pygtk has any less right to install a log handler than, say, epiphany. Surely you can save/restore the log handler in the code that embeds pygtk in epiphany?...
Maybe if we detect when pygtk is being used embedded we could disable the log handler in this case...
I moved the addition of the log handlers to __init__.py and added a new function, gtk.remove_log_handlers() which can be used to remove the already installed log handlers in PyGTK. It can be used by normal applications as well as programs embedding PyGTK. CVS commit: Checking in ChangeLog; /cvs/gnome/gnome-python/pygtk/ChangeLog,v <-- ChangeLog new revision: 1.1399; previous revision: 1.1398 done Checking in gtk/__init__.py; /cvs/gnome/gnome-python/pygtk/gtk/__init__.py,v <-- __init__.py new revision: 1.36; previous revision: 1.35 done Checking in gtk/gtk.override; /cvs/gnome/gnome-python/pygtk/gtk/gtk.override,v <-- gtk.override new revision: 1.353; previous revision: 1.352 done Checking in gtk/gtkmodule.c; /cvs/gnome/gnome-python/pygtk/gtk/gtkmodule.c,v <-- gtkmodule.c new revision: 1.65; previous revision: 1.64 done
Aren't there handlers for pango and gobject/glib as well? I wonder if this is a good time to convert them to packages so there's an __init__.py for them and more can be pulled out into python code. BTW, I'm supposedly on vacation now so it will probably be next week before I can look at the new developments in CVS.
(In reply to comment #3) > I moved the addition of the log handlers to __init__.py and > added a new function, gtk.remove_log_handlers() which can be > used to remove the already installed log handlers in PyGTK. > It can be used by normal applications as well as programs > embedding PyGTK. This is not a fix! It only removes handlers installed by gtk module, and there are yet pango, gobject, and whatnot. This remove_handlers() thing is pretty wrong, since it's used only to undo setting log handlers. It would be much better if there was a way to tell all pygtk modules not to install log handlers in the first place (and environment variable would work just fine). And no, gtk.remove_log_handlers(); pango.remove_log_handlers(); gobject.remove_log_handlers(); some_module_i_never_heard_about.remove_log_handlers() is not a solution. At the moment I have to use special object for sys.stderr to make pygtk log handlers use mine (I have a log window or write log stuff into a file), and it complicates things pretty much, since python module must be aware of my log handlers (and well, it's really stupid to write code for this). Note, this is not as weird as it might seem. On windows, you can't run an application from a terminal, and see console output. And in case of problems it's extremely important to be able to get log output. (In reply to comment #1) > I don't see why pygtk has any less right to install a log handler than, say, > epiphany. Because it's a library! It's application business to decide what it wants to do, not library's. While it's right for pygtk to install its log handlers to make it better for people writing python scripts, it should not make it hard for people embedding python.
I'd love to be able to figure out automatically when pygtk is being used embeded. Any ideas for that?
Created attachment 64931 [details] [review] gobject patch How about something like this? All modules would use it, and it could be disabled with single call once and forever.
Aside for the fact that the global variables log_handlers and log_handlers_disabled need to be initialized, it's an interesting patch. But still, I'd rather have this "just work", instead of requiring applications to call a pygobject API to disable logging. I'd like some time to try to come with something along that line; if I fail, I don't object to fallback to this patch.
(In reply to comment #8) > Aside for the fact that the global variables log_handlers and > log_handlers_disabled need to be initialized, it's an interesting patch. They are static.
Created attachment 64949 [details] [review] whole thing Here's a whole thing. It leaks warning objects, but it does demonstrate how silly it is to add api for removing log handlers instead of not setting them in the first place. One environment variable could save the world and make everyone happy! By the way, is this bug really fixed/closed and should I open a new one?
pygobject patch committed with slight changes; pygtk part needed changes to cope with possibly older pygobject. Next step is to figure out if we can preemptively disable warning redirections by looking at e.g. Py_GetProgramName.
I think attempts to decide to install the log functions automatically are not going to work. An example is Wing, which is run as a wing.exe binary on win32 (because an icon is easily bound to the .exe) and as 'python wing.py' every where else. I can change wing's code to accomodate any change, but there are probably other programs that are affected. My suggestion for an api is to have a global flag (install_log_handlers?) in pygtk.py that gets checked when a module is imported. If it's true, the handlers are added and if it's not, they're not installed. Please do not use environment variables because they're too easily inherited by subprocesses. There could also be mechanisms to remove all or some handlers and to install them again once they are removed.
(In reply to comment #12) > My suggestion for an api is to have a global flag (install_log_handlers?) in > pygtk.py that gets checked when a module is imported. If it's true, the > handlers are added and if it's not, they're not installed. Please do not use > environment variables because they're too easily inherited by subprocesses. Good point, and nice solution. > There could also be mechanisms to remove all or some handlers and to install > them again once they are removed. Does someone need it? So far it's needed to remove all handlers once and forever. If someone would need to install them back, then he would probably need a full-blown wrapper for glib logging functions.
(In reply to comment #12) > I think attempts to decide to install the log functions automatically are not > going to work. An example is Wing, which is run as a wing.exe binary on win32 > (because an icon is easily bound to the .exe) and as 'python wing.py' every > where else. I can change wing's code to accomodate any change, but there are > probably other programs that are affected. Hmm.. but is wing.exe an IDE only, or is it also a python interpreter. How are _python programs_ executed in WinIDE? Does it call an external python interpreter, or does it run the python code itself? The idea of redirecting log warnings is to help developers pinpoint the source of gtk warnings in their python code. Do developers test their code with anything else than a standard "i?python([09]*)(.exe)?". > My suggestion for an api is to have a global flag (install_log_handlers?) in > pygtk.py that gets checked when a module is imported. If it's true, the > handlers are added and if it's not, they're not installed. But we don't want to make this flag global for all applications. We want log handlers for python interpreters, just not for applications embedding python. > Please do not use environment variables because they're too easily inherited by subprocesses. Yes, I agree. None was used. > There could also be mechanisms to remove all or some handlers and to install > them again once they are removed. There is a new pygobject API to remove all current and future log handlers, in addition to an API to add a specific log handler. PS: I decided to call them "warning redirections" rather than "log handlers" because it doesn't allow arbitrary log handlers. It is only meant to handle warnings.
(In reply to comment 13) Maybe it's ok to leave some of the functionality out on YAGNI grounds, though I was thinking of the (theoretical?) case of someone removing the handlers for some time and then restoring them. (In reply to comment 14) Wing here is an example of a pygtk application that wants the handlers installed, but does not always run w/ sys.executable == python. Anything packaged with py2exe probably also has the same issue. On the flip side, I can easily imagine apps run under python not wanting the log handler; maybe for performance reasons. The point is that this is guessing and it's easy to be wrong, so don't guess. Instead, provide an api through which the developer can choose whether to install the handler. BTW, if the handlers aren't installed in some situations (if the guessing based on sys.executable is implemented for example), then there needs to be an api to explicitly install them.
(In reply to comment #15) > The point is that this is guessing and it's easy to be > wrong, so don't guess. Instead, provide an api through which the developer can > choose whether to install the handler. Right now, log handlers are installed by default, and can be removed/disabled by calling a C API. Does that suit you, if we leave it like that?
It works for me. I kind of like the idea of a constant in pygtk.py to control it so it's more visible, but it's not a big deal.
But we don't want it 'constant', we want per-application control, so... Closing.
Ok, but putting the flag variable in pygtk.py would make it settable for each application. Usage would be something like: import pygtk pygtk.require('2.0') pygtk.install_warning_handlers = False import gtk Just seems a bit cleaner never to install the handlers rather than install and then remove them.
Please don't add more functionallity to the pygtk module. I want it to go away as soon as possible. Embedding is not the common use case anyway, it's not a big deal to require embedders to remove signal handlers manually.