[Twisted-Python] Re: [Twisted-commits] r14614 - Describe log.debug, and 'printed' and 'debug' log dict items.
On Thu, 2005-09-29 at 23:17 -0600, Andrew Bennetts wrote:
Author: spiv Date: Thu Sep 29 23:17:15 2005 New Revision: 14614
Modified: trunk/doc/core/howto/logging.xhtml Log: Describe log.debug, and 'printed' and 'debug' log dict items.
log.debug should die, I think. So it probably shouldn't be documented :)
On Fri, Sep 30, 2005 at 05:10:20PM -0400, Itamar Shtull-Trauring wrote:
On Thu, 2005-09-29 at 23:17 -0600, Andrew Bennetts wrote:
Author: spiv Date: Thu Sep 29 23:17:15 2005 New Revision: 14614
Modified: trunk/doc/core/howto/logging.xhtml Log: Describe log.debug, and 'printed' and 'debug' log dict items.
log.debug should die, I think. So it probably shouldn't be documented :)
I was also told this by radix on IRC. I see no deprecation warnings. I documented it because I noticed a colleague of mine independently found and used it, and I'd never heard of it, so I corrected that, because it's clearly part of the public API at the moment. If someone who feels confident that they understand the intent of twisted.python.log well enough wants to stick their neck out and deprecate debug, please do. I'm not that person. I'm not inclined to remove reference to debug from logging.xhtml until it is actually deprecated. Corrections and reviews of the logging documentation are most welcome, though! -Andrew.
log.debug should die, I think. So it probably shouldn't be documented :)
I was also told this by radix on IRC.
I see no deprecation warnings. I documented it because I noticed a colleague of mine independently found and used it, and I'd never heard of it, so I corrected that, because it's clearly part of the public API at the moment. If someone who feels confident that they understand the intent of twisted.python.log well enough wants to stick their neck out and deprecate debug, please do. I'm not that person.
Also, a few words to the effect of *why* it should be deprecated would be useful. We use it quite a lot, and I'd appreciate a few comments. It wouldn't be a big problem should it go away, since we already monkeypatch t.p.logging a lot, but it is still bewildering to see such comments without any explanation. -- Nicola Larosa - nico@tekNico.net How much of what we are should we be proud of? When did we choose the things that made us smart, knowledgeable, or successful? Should we be proud? Should we feel superior? Maybe we should just be grateful. -- jgoldblog, May 2002
On Oct 4, 2005, at 12:20 AM, Nicola Larosa wrote:
Also, a few words to the effect of *why* it should be deprecated would be useful. We use it quite a lot, and I'd appreciate a few comments.
Me, too, me too. In my day job, I develop a lot of Java code. We have the luxury of granular logging. I can switch, on a per-class basis, the output level to trace, debug, warn, error, or fatal. That's handy. In Twisted, I see log.msg(), log.debug(), and log.err(). Why is one of these levels going away? Is it just not normal to use logging for debugging? What do you do instead? -- Scott Lamb <http://www.slamb.org/>
On Tue, 2005-10-04 at 10:00 -0700, Scott Lamb wrote:
In my day job, I develop a lot of Java code. We have the luxury of granular logging. I can switch, on a per-class basis, the output level to trace, debug, warn, error, or fatal. That's handy.
In Twisted, I see log.msg(), log.debug(), and log.err(). Why is one of these levels going away? Is it just not normal to use logging for debugging? What do you do instead?
twisted.python.log needs to be rewritten to support more modular logging; the new API would be "log.msg(something, interface=IFoo)" where IFoo might be IMessage, or IHTTPRequest for the webserver log, etc.. We don't have thay yet, unfortunately. log.debug() as it works now is just broken, it doesn't add anything to log.msg() in a reasonable way.
On Tue, 4 Oct 2005 10:00:58 -0700, Scott Lamb <slamb@slamb.org> wrote:
On Oct 4, 2005, at 12:20 AM, Nicola Larosa wrote:
Also, a few words to the effect of *why* it should be deprecated would be useful. We use it quite a lot, and I'd appreciate a few comments.
Me, too, me too.
In my day job, I develop a lot of Java code. We have the luxury of granular logging. I can switch, on a per-class basis, the output level to trace, debug, warn, error, or fatal. That's handy.
In Twisted, I see log.msg(), log.debug(), and log.err(). Why is one of these levels going away? Is it just not normal to use logging for debugging? What do you do instead?
One of the functions is going away. A level isn't going away, because twisted.python.log does not have the notion of "levels" present in other logging systems. What you can log with twisted.python.log is an event. A very common kind of event is a byte string - log.msg is often used to emit one of these, but it can emit any kind of event. Another common event corresponds to an error and is represented by a twisted.python.failure.Failure instance - log.err is a convenience function to construct a Failure from the current Python exception state and emit it. log.debug is this warty thing that emits a string but also attaches {"debug": 1} to it. This is completely ignored by the log observer Twisted actually includes. To emphasize that point, in the default configuration, log.msg() does exactly the same thing as log.debug(). So, it's pointless. The functionality might be useful, although I've never found it such (print is pretty easy to use, and Python is too slow to leave in debug messages after debugging is finished). As Itamar pointed out in his post, we have some ideas about providing a lot more structure for the event system, but we haven't gotten around to implementing it. Once we do, there will be much richer facilities for this kind of behavior. Jp
On Oct 4, 2005, at 1:00 PM, Scott Lamb wrote:
On Oct 4, 2005, at 12:20 AM, Nicola Larosa wrote:
Also, a few words to the effect of *why* it should be deprecated would be useful. We use it quite a lot, and I'd appreciate a few comments.
Me, too, me too.
In my day job, I develop a lot of Java code. We have the luxury of granular logging. I can switch, on a per-class basis, the output level to trace, debug, warn, error, or fatal. That's handy.
In Twisted, I see log.msg(), log.debug(), and log.err(). Why is one of these levels going away? Is it just not normal to use logging for debugging? What do you do instead?
The "log levels", such as they are, are (and have been for ages) implemented as keyword args on msg: log.msg("error message", isError=1) log.msg("normal message") log.msg("debug message", debug=1). The log.debug function just added the debug=1 argument for you. The log.err func is poorly named, because you might be tempted to use it to emit error-level info, when really it is for emitting Exception/ Failure objects. All in all, the log level functionality in twisted.python.log is pretty silly, but substantially unchanged. James
On Tue, 4 Oct 2005 16:31:58 -0400, James Y Knight <foom@fuhm.net> wrote:
log.msg("error message", isError=1)
Please don't ever do this. Log observers which check the isError flag expect a stricter interface; a Failure object, for one thing, like log.err puts there. Really this should be using the interface keyword arg that itamar mentioned, set to something like log.IErrorReport. To ensure portability when that does become the convention, use log.err.
On Oct 4, 2005, at 5:01 PM, glyph@divmod.com wrote:
On Tue, 4 Oct 2005 16:31:58 -0400, James Y Knight <foom@fuhm.net> wrote:
log.msg("error message", isError=1)
Please don't ever do this. Log observers which check the isError flag expect a stricter interface; a Failure object, for one thing, like log.err puts there.
Actually they don't. They expect that the failure keyword may or may not be present. The only use of "levels" we have (DefaultObserver only showing error messages) filters out any non-isError messages, so there are circumstances in which you want to make sure you're emitting an isError=1 message.
Really this should be using the interface keyword arg that itamar mentioned, set to something like log.IErrorReport. To ensure portability when that does become the convention, use log.err.
But sometimes you cannot use log.err because you want to emit an error-level _message_, rather than the repr of an object, an exception, or a failure. Notice how log.err("Foo!") doesn't actually do what you might hope. Contrast with log.msg("Foo!", isError=1) which does. James
On Tue, 4 Oct 2005 23:18:40 -0400, James Y Knight <foom@fuhm.net> wrote:
On Oct 4, 2005, at 5:01 PM, glyph@divmod.com wrote:
On Tue, 4 Oct 2005 16:31:58 -0400, James Y Knight <foom@fuhm.net> wrote:
log.msg("error message", isError=1)
Please don't ever do this. Log observers which check the isError flag expect a stricter interface; a Failure object, for one thing, like log.err puts there.
Actually they don't. They expect that the failure keyword may or may not be present. The only use of "levels" we have (DefaultObserver only showing error messages) filters out any non-isError messages, so there are circumstances in which you want to make sure you're emitting an isError=1 message.
Really this should be using the interface keyword arg that itamar mentioned, set to something like log.IErrorReport. To ensure portability when that does become the convention, use log.err.
But sometimes you cannot use log.err because you want to emit an error- level _message_, rather than the repr of an object, an exception, or a failure.
Notice how log.err("Foo!") doesn't actually do what you might hope. Contrast with log.msg("Foo!", isError=1) which does.
Neither of these is supported behavior. They're implementation accidents and shouldn't be used. It's understandable that this is surprising, since I doubt it's ever been written down anywhere. Jp
On Tue, Oct 04, 2005 at 11:49:04PM -0400, Jp Calderone wrote:
On Tue, 4 Oct 2005 23:18:40 -0400, James Y Knight <foom@fuhm.net> wrote: [...]
Notice how log.err("Foo!") doesn't actually do what you might hope. Contrast with log.msg("Foo!", isError=1) which does.
Neither of these is supported behavior. They're implementation accidents and shouldn't be used. It's understandable that this is surprising, since I doubt it's ever been written down anywhere.
Would you mind reviewing logging.xhtml to make sure it's perfectly correct about these matters, then? I made the best educated guesses about the intentions of the code that I could, but I might have made some mistakes. -Andrew.
participants (7)
-
Andrew Bennetts -
glyph＠divmod.com -
Itamar Shtull-Trauring -
James Y Knight -
Jp Calderone -
Nicola Larosa -
Scott Lamb