Christian Robottom Reis
kiko at async.com.br
Fri Jun 18 03:49:14 WST 2004
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
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?
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331
More information about the pygtk