Re: [Zope] logging module in Zope?
From: "Richard Jones" <richardjones@optushome.com.au>
Because the Zope logging functionality is really quite poor? Ever asked yourself why it's called "stupid" logging?
It isn't. It's the logging to a file thats called "stupid file log". Thats because it is just one file that events get logged in. It's a rather simple/stupid system. But thats not all that there is to Zopes logging. 1. Peter Bengtsson still haven't said why he doesn't want to use Zopes logging system. 2. And neither have you said what is "poor" about Zopes logging. 3. And unless you want to end up with two different logging systems (which usually is not what you want, since you only end up looking in two places), you would need to use Zopes logging, but replace/extend that one with the relevant parts of python_logging or whatever logging you want.
On Sunday 07 April 2002 05:03 am, Lennart Regebro wrote:
From: "Richard Jones" <richardjones@optushome.com.au>
Because the Zope logging functionality is really quite poor? Ever asked yourself why it's called "stupid" logging?
for the record, the logging module referred to was done as implementation of a python logging pep, and as such has some chance of becoming standard as in distributed with python.
It isn't. It's the logging to a file thats called "stupid file log". Thats because it is just one file that events get logged in. It's a rather simple/stupid system. But thats not all that there is to Zopes logging.
yup, plus actually trivial to wrap zope's logging with a more friendly interface that does distinguish local names, one thing i've started doing is wrapping zope's logging system with a few extras, ie a call to register subsystem for a separate log name for my product register_subsystem('my product') a class which wraps calls to zLog inserting extra useful info ( a component name, user_id, thread id) something akin to the following class Log: def debug(self, *args): pass def fatal(self, *args): pass and then a factory function taking the name of the subcomponent which returns a log instance which will prefix logs with both the product name (subsystem) and the component name. def LogFactory(self, appname): return Log
1. Peter Bengtsson still haven't said why he doesn't want to use Zopes logging system.
ok, i think he has, and it can be worked around to some extent by layering your own api over zope's but that in and of itself isn't very standard.
2. And neither have you said what is "poor" about Zopes logging.
personally i don't like the api, i prefer
log.debug(message) to
LOG(msg, INFO, extra)
3. And unless you want to end up with two different logging systems (which usually is not what you want, since you only end up looking in two places), you would need to use Zopes logging, but replace/extend that one with the relevant parts of python_logging or whatever logging you want.
i think that its a relevant to consider this module if only because it has some chance of becoming a standard python idiom, although perhaps not of great relevance to zope2x. cheers kapil
From: "kapil thangavelu" <kthangavelu@earthlink.net>
1. Peter Bengtsson still haven't said why he doesn't want to use Zopes logging system.
ok, i think he has
I missed that in that case.
personally i don't like the api, i prefer
log.debug(message) to
LOG(msg, INFO, extra)
Well, as simple as possible is good, but sending subsystem, level and message is the minimum. If you do it with log(sys, level, msg) or log.level(sys, msg) doesn't really matter...
i think that its a relevant to consider this module if only because it has some chance of becoming a standard python idiom, although perhaps not of great relevance to zope2x.
Depends on when your log becomes standard and how long Zope 2 lives on. :-)
participants (2)
-
kapil thangavelu -
Lennart Regebro