On Thu, Jun 17, 2004 at 03:41:52PM -0400, John Ehresman wrote: > Tim Newsham wrote: > >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.
Note also that whatever functions we need to expose means more code to maintain and keep up to date as time goes by. It makes a lot of sense to rely on base Python functionality and only wrap or adapt what is actually necessary. I also like gjc's recommendation to route all glib warnings through Python warnings -- it's just so much easier to handle from there. Of course, some people might *want* the original handling, so we'd need a way to turn it off, I guess. Any API suggestions? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
