On Sun, Jun 7, 2009 at 12:53 PM, Chris Withers <chris@???>wrote:
>
> Ian Bicking wrote:
> > I think you miss the point here: WebError shouldn't care how or
> > where the log messages are delivered, otherwise it has to start
> > caring about all the possible options it wants. Simply logging an
> > exception to the logging framework is simple and robust.
> >
> > Have you looked at the HTML emails that weberror sends? I think they
> > are quite nice and have a lot of good useful information in them, and I
> > can't imagine how you'd stuff that into a logging message.
>
> I'll give it a go then :-)
>
More power to ya'
>
> > It doesn't address dynamically scoped logging levels, for instance.
>
> What do you mean by that?
>
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.
>
> > It
> > doesn't make it easy to provide logging context.
>
> Again, what do you mean by that?
>
In the case of web development, any logging message really needs to be
mappable to the request it came from. 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).
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.
>
> > It doesn't make it
> > easy to have logging messages that are anything but text (like HTML).
>
> Well, I see that as a good thing ;-)
>
Well, our opinions differ considerably then ;)
>
> > It doesn't allow for nested routing.
>
> Again, what do you mean by that?
>
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.
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, one of which is statically
determined, others which are more dynamic.
>
> > It prefers static logging
> > definitions, but I find dynamic (based on the call stack) to be more
> > natural.
>
> Er, at the risk of repeating myself, what do you mean by that?
> In prettymuch all of your comments above, you're using words that are so
> generic that they have no meaning nowadays: context, "dynamically
> scoped", etc
>
> > It's easy to turn it up or down, but usually I don't care
> > about *any* logging messages (when everything is working),
>
> Well, I work on the basis that when everything is working, there should
> be no log messages emitted above INFO, so I get everything above that
> emailed to me, and stuff *at* INFO logged to a file. If debugging is
> needed, I just turn on logging for everything to the file.
>
> > about *all* of them (when anything fails). The configuration format is
> > lame.
>
> 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.
>
> > It introduces one too many abstractions between loggers and
> > handlers and formatters.
>
> I think the difference between loggers, handlers and formatters is just
> perfect. In fact, most of your problems above could probably be solved
> by a formatter that took a template from a file and used it to format
> you logging calls, it could even spit out html, although that might look
> funny in a log file ;-) BUT, you could then write a handler that logged
> each entry into a .html file rather than one long file, and all would be
> good. I've written handlers that group together log entries and send
> them at the end of the process (SummarisingLogger) and I think the same
> might work for grouping per-request. "Context" is just what you pass to
> the log calls, again, a fancy formatter could probably pull in context
> when it's called...
>
> > I could go on.
>
> Please explain your current concerns in more detail before you do ;-)
>
> > If you *did* want per-request logging, it'd be pretty trivial to
> > write a piece of middleware that added a handler for the duration of
> > the request and removed it afterwards.
> >
> >
> > 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. How does
PerRequestHandler get access to the request when a logging messages comes
through?
--
Ian Bicking | http://blog.ianbicking.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
