Ian Bicking wrote:
> Let's say you have a function:
>
> def do_stuff():
> if some_condition:
> logging.warn('your fizbat is on the fritz; continuing without fiz')
>
> And you have code that calls do_stuff(), but you decide that in the
> scope of your application you don't really feel that fiz is that
> important, so you want to have it show up as simply an info level
> argument. Sometimes this is really a per-function-call situation. For
> instance, when dealing with subprocesses, you might have a function that
> runs them, but only the caller really knows what to expect from the
> subprocess call, so adjustments to how logging is performed need to be
> per-call.
two comments on this:
- logging is a bit like writing unit or functional tests; it's a bit of
an art. My take on this is that when the logging is "right", you won't
need the kind of configuration you're asking for. Either that, or it can
be put in by hand when you need it and removed straight away afterwards.
Having this all "in code" feels overcomplicated and likely to bog things
down.
- how would you spell what it is that you want here? (I guess in the
calling code?)
> In the case of web development, any logging message really needs to be
> mappable to the request it came from.
Well, any log message should include enough information to convey its
message usefully, but no more. I don't want the whole detail of every
single request logged every single time ;-)
> In most cases there's some
> context that explains the logging (for instance, if SQL is logged, you
> want to know what the reason is that this SQL is being run, which is a
> kind of context).
Wouldn't your "per request handler" wrap all the relevant log messages
together in one lump and give all the context needed without a massively
bulky context being logged for every single log line?
FWIW, I've never had problems tying up different log messages with their
context, the "time" key usually lets you tie up stuff across different
types of logs (Apache, python web server, db server).
> You can achieve this by logging the hell out of everything, but this
> leads to verbosity -- constantly and preemptively emitting messages
> about context because maybe some later logging message will only make
> sense because of that context.
I agree, but I don't understand what you're driving at here. First you
say you want context, then you say that logging context is bad because
of verbosity... make your mind up ;-)
> Well, I see that as a good thing ;-)
>
> Well, our opinions differ considerably then ;)
Which is why configurability is good!
> Often I'd like to be able to catch all the logging for a particular
> call, then decide if it was important. It can be done, but you have to
> jump through hoops, and it should just be easy.
How do you currently spell it and how would you like to be able to spell it?
> Also, loggers tend to be statically bound to a single name. I'd rather
> they be more like a set of categories on the logging,
You sure this isn't just a point of view?
I've always thought of getLogger('whatever') as "get me somewhere I can
log stuff for the 'whatever' category" rather than "get me the logger
called 'whatever'"...
> one of which is
> statically determined, others which are more dynamic.
Need more explanation for these words to make sense ;-)
> I'm not gonna argue there, but then I think all .ini config is lame.
> ZConfig comes with sections for all the default loggers, and I much
> prefer its config file format.
>
> Mostly as an aside, ZConfig is a dead end at this point.
That's interesting, what makes you say that?
I find ZConfig extremely useful and *much* prefer the nested
Apache-style of config rather than the horrible mess that is .ini-style
configuration.
> > It has to be thread-local, which isn't trivial.
>
> Why? I'd imagined setting you something like:
>
> logger.addHandler(PerRequestHandler(id(request)))
>
> ...and then it would filter out anything that didn't match the id it was
> initialised with.
>
> Well, you'd also have to tear that down for every request as well.
logger.removeHandler(x) really isn't such a chore ;-)
(I don't think it's expensive either)
> How
> does PerRequestHandler get access to the request when a logging messages
> comes through?
I guess that depends on your web framework. In Pylons, it's an important
global thingy anyway. For others, PerRequestHandler could actually be
initialised with the request.
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Paste Users" group.
To post to this group, send email to paste-users@???
To unsubscribe from this group, send email to paste-users+unsubscribe@???
For more options, visit this group at
http://groups.google.com/group/paste-users?hl=en
-~----------~----~----~----~------~----~------~--~---
