Re: [pygtk] g_log_set_handler?
A Seg, 2004-07-05 às 18:47, John Ehresman escreveu: > Gustavo J. A. M. Carneiro wrote: > > Did this. All (and only) Gtk warnings now are caught and raised as > > python warnings. The advantage of doing so is that by default python > > shows the python source file and line number that caused the warning to > > be raised. Also, warnings can be turned into exceptions or redirected > > somewhere else. > > Thanks, I generally agree with this approach. There's a practical > problem on Windows, though, because a GUI application should redirect > all log domains to prevent a console window from appearing when > something is printed to stdout or stderr. Currently, Wing redirects the > following domains: NULL, "Pango", "Gtk", "Gdk", "GLib", "GLib-GObject". > > Maybe pygtk should redirect more domains and provide an api to add new > redirected domains. +1 Regards. -- Gustavo João Alves Marques Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] g_log_set_handler?
Gustavo J. A. M. Carneiro wrote: Did this. All (and only) Gtk warnings now are caught and raised as python warnings. The advantage of doing so is that by default python shows the python source file and line number that caused the warning to be raised. Also, warnings can be turned into exceptions or redirected somewhere else. Thanks, I generally agree with this approach. There's a practical problem on Windows, though, because a GUI application should redirect all log domains to prevent a console window from appearing when something is printed to stdout or stderr. Currently, Wing redirects the following domains: NULL, "Pango", "Gtk", "Gdk", "GLib", "GLib-GObject". Maybe pygtk should redirect more domains and provide an api to add new redirected domains. 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/
Re: [pygtk] g_log_set_handler?
A Qui, 2004-06-17 às 11:41, Gustavo J. A. M. Carneiro escreveu: > A Qua, 2004-06-16 às 23:32, Tim Newsham escreveu: > > Hi, Is there any way to set the log handler in pygtk? I couldn't > > find any. I did notice a previous related thread on > > "turning tk warnings into exceptions." I am interested > > in altering the default warning logging mechanism. Currently > > under windows it forces a console window to open up to > > emit these warnings. I know that ideally the code would > > be warning free, but I still get occasional harmless warnings > > from gtk and glade. > > I think pygtk should install a log handler to turn all log messages > into python warnings. Then, the pygtk programmer may use the standard > 'warnings' module to do whatever he wishes to such warnings: hide them, > turn them to exceptions, show in a text/list widget, etc. > > If you are interested in this, you should open a bug report in > bugzilla.gnome.org, product pygtk, type enhancement. A patch will speed > up the bug progress, but otherwise I will eventually do this, but it may > take some time. Did this. All (and only) Gtk warnings now are caught and raised as python warnings. The advantage of doing so is that by default python shows the python source file and line number that caused the warning to be raised. Also, warnings can be turned into exceptions or redirected somewhere else. In the future we might want to handle other logging domains, such as libgnome. But the Gtk domain is by far the most important one. For general logging, I don't think we should wrap g_log_set_handler. It duplicates the functionality of the standard python modules 'warnings' and 'logging'. I hope no one disagrees with this, because it's done. ;-) Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] g_log_set_handler?
On Fri, Jun 18, 2004 at 09:44:50AM +1200, Tim Evans wrote: > > I think that maybe the Python 'logging' module would be a better choice > than Python warnings. > >http://docs.python.org/lib/module-logging.html The idea I had was that the logging module was for application-level messages, not toolkit-level ones. Granted, some packages like the ZODB use it throughout, but in general I would consider using logging to convey PyGTK messages a bit awkward, since they aren't really application-level messages. Is this not the case? > The different levels of g_log would be translated into the equivalent > Python logging levels as follows: > > G_LOG_LEVEL_ERROR logging.CRITICAL > G_LOG_LEVEL_CRITICAL logging.ERROR > G_LOG_LEVEL_WARNINGlogging.WARNING > G_LOG_LEVEL_MESSAGE25 (between WARNING and INFO) > G_LOG_LEVEL_INFO logging.INFO > G_LOG_LEVEL_DEBUG logging.DEBUG I feel that the match between GTK+ warnings and Python warnings is quite a good one, since they both mean something similar in a very low-level sense (that you're doing something code-wise that isn't quite right, but that is probably easily fixed). I don't know, however, how reasonably the other levels would match up to Python exception semantics. 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/
Re: [pygtk] g_log_set_handler?
Gustavo J. A. M. Carneiro wrote: A Qua, 2004-06-16 às 23:32, Tim Newsham escreveu: Hi, Is there any way to set the log handler in pygtk? I couldn't find any. I did notice a previous related thread on "turning tk warnings into exceptions." I am interested in altering the default warning logging mechanism. Currently under windows it forces a console window to open up to emit these warnings. I know that ideally the code would be warning free, but I still get occasional harmless warnings from gtk and glade. I think pygtk should install a log handler to turn all log messages into python warnings. Then, the pygtk programmer may use the standard 'warnings' module to do whatever he wishes to such warnings: hide them, turn them to exceptions, show in a text/list widget, etc. If you are interested in this, you should open a bug report in bugzilla.gnome.org, product pygtk, type enhancement. A patch will speed up the bug progress, but otherwise I will eventually do this, but it may take some time. I think that maybe the Python 'logging' module would be a better choice than Python warnings. http://docs.python.org/lib/module-logging.html The different levels of g_log would be translated into the equivalent Python logging levels as follows: G_LOG_LEVEL_ERROR logging.CRITICAL G_LOG_LEVEL_CRITICAL logging.ERROR G_LOG_LEVEL_WARNINGlogging.WARNING G_LOG_LEVEL_MESSAGE25 (between WARNING and INFO) G_LOG_LEVEL_INFO logging.INFO G_LOG_LEVEL_DEBUG logging.DEBUG The transposition of meanings for "critical" and "error" is unfortunate, but I guess we could live with it. Handling fatal G_LOG_LEVEL_ERROR messages may not be useful anyway. A heirachy of loggers would be created, with something like 'glog' at the top, and a child logger for each log domain, i.e.: 'glog.Gtk', 'glog.GLib', 'glog.Pango', etc. We would also need to define a few useful gtk-related logging.Handler classes, such as TextBufferHandler, ListStoreHandler, etc. I think that all of this should go into a module called 'glog'. If anyone else likes this idea I could try putting together an initial version of such a module. -- Tim Evans Applied Research Associates NZ http://www.aranz.com/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] g_log_set_handler?
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/
Re: [pygtk] g_log_set_handler?
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. 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/
Re: [pygtk] g_log_set_handler?
> I think pygtk should install a log handler to turn all log messages > into python warnings. Then, the pygtk programmer may use the standard > 'warnings' module to do whatever he wishes to such warnings: hide them, > turn them to exceptions, show in a text/list widget, etc. 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. Since pygtk is a package that exposes GTK API's to python, this seems like the appropriate thing to do. > Gustavo João Alves Marques Carneiro Tim N. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] g_log_set_handler?
A Qui, 2004-06-17 às 16:52, John Ehresman escreveu: > Gustavo J. A. M. Carneiro wrote: > > I think pygtk should install a log handler to turn all log messages > > into python warnings. Then, the pygtk programmer may use the standard > > 'warnings' module to do whatever he wishes to such warnings: hide them, > > turn them to exceptions, show in a text/list widget, etc. > > Interesting idea; I think this should be an option and maybe should be > the default behavior. The patch I submitted as part of the patch to > create a glib module simply wraps the log_set_handler function so that a > Python callable can be used as the handler. Right. I was not thinking it even as option. PyGTK would _always_ install a log handler, at startup, that would capture all warning messages and inject them into python's warning module. Then, if the programmer wants to intercept warnings, he would use the standard python API. I think that this way GTK blends better with Python, and the programmer doesn't have to learn two logging APIs. Regards. -- Gustavo João Alves Marques Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] g_log_set_handler?
Christian Robottom Reis wrote: Speaking of this patch, we should start discussion on whether we want it in for 2.4 or not. Johan (and someone else?) has expressed reservations because he feels that most of it duplicates functionality already in the Python standard library. I'm sure you have a good argument against that one already :-) I agree with him :). I think the basic glib patch should go in, without exposing IOChannel's. IOChannel's can be added later if there is a need. 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/
Re: [pygtk] g_log_set_handler?
> Speaking of this patch, we should start discussion on whether we want it > in for 2.4 or not. Johan (and someone else?) has expressed reservations > because he feels that most of it duplicates functionality already in the > Python standard library. I'm sure you have a good argument against that > one already :-) Not the g_log_set_handler, I'd like to have them in. It's mostly the GIOChannel I don't want in which I think you're confusing. The patch actually wraps both so I can't blame you for that. -- Johan Dahlin <[EMAIL PROTECTED]> ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] g_log_set_handler?
On Thu, Jun 17, 2004 at 11:52:57AM -0400, John Ehresman wrote: > Gustavo J. A. M. Carneiro wrote: > > I think pygtk should install a log handler to turn all log messages > >into python warnings. Then, the pygtk programmer may use the standard > >'warnings' module to do whatever he wishes to such warnings: hide them, > >turn them to exceptions, show in a text/list widget, etc. > > Interesting idea; I think this should be an option and maybe should be > the default behavior. The patch I submitted as part of the patch to > create a glib module simply wraps the log_set_handler function so that a > Python callable can be used as the handler. Speaking of this patch, we should start discussion on whether we want it in for 2.4 or not. Johan (and someone else?) has expressed reservations because he feels that most of it duplicates functionality already in the Python standard library. I'm sure you have a good argument against that one already :-) 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/
Re: [pygtk] g_log_set_handler?
Gustavo J. A. M. Carneiro wrote: I think pygtk should install a log handler to turn all log messages into python warnings. Then, the pygtk programmer may use the standard 'warnings' module to do whatever he wishes to such warnings: hide them, turn them to exceptions, show in a text/list widget, etc. Interesting idea; I think this should be an option and maybe should be the default behavior. The patch I submitted as part of the patch to create a glib module simply wraps the log_set_handler function so that a Python callable can be used as the handler. 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/
Re: [pygtk] g_log_set_handler?
> If you are interested in this, you should open a bug report in > bugzilla.gnome.org, product pygtk, type enhancement. A patch will speed > up the bug progress, but otherwise I will eventually do this, but it may > take some time. John Ehresman already wrote one, it's included in the tarball in the GIOChannel bug (which # I can't remember) -- Johan Dahlin <[EMAIL PROTECTED]> ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] g_log_set_handler?
A Qua, 2004-06-16 às 23:32, Tim Newsham escreveu: > Hi, Is there any way to set the log handler in pygtk? I couldn't > find any. I did notice a previous related thread on > "turning tk warnings into exceptions." I am interested > in altering the default warning logging mechanism. Currently > under windows it forces a console window to open up to > emit these warnings. I know that ideally the code would > be warning free, but I still get occasional harmless warnings > from gtk and glade. I think pygtk should install a log handler to turn all log messages into python warnings. Then, the pygtk programmer may use the standard 'warnings' module to do whatever he wishes to such warnings: hide them, turn them to exceptions, show in a text/list widget, etc. If you are interested in this, you should open a bug report in bugzilla.gnome.org, product pygtk, type enhancement. A patch will speed up the bug progress, but otherwise I will eventually do this, but it may take some time. Regards. -- Gustavo João Alves Marques Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
