I'm not sure why a new mechanism is needed. GLIB already provides a mechanism for intercepting the log messages (g_log_set_handler). If this was exposed in pygtk, then a programmer could intercept the log messages, redirect them as python warnings, or do whatever else they wanted to do with them.
This is a case where Python and gtk provide similar functionality and it may make sense to route gtk warnings through the Python warning framework because then there would one way to capture all warnings. From the standpoint of Python, the glib logging mechanism is the new mechanism. Another example of duplicate functionality is character set conversion: Python has unicode support so there's no need to expose the equivalent glib functions.
John
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
