On May 28, 8:55 pm, Kevin howerton <kevin.hower...@gmail.com> wrote:
> I see the utility of being able to have additional ways to setup the
> logging, though as it is I think the biggest issue people have with
> the logging stuff is that the dictconfig is already fairly
> intimidating looking. If someone really wants to disable the default
> setup of logging, it should be as simple as flipping a setting, then
> calling their own loggers by hand in settings or __init__.
I agree that there should be a simple option for configuration - and
in my example application, the LOGGING dict is used to configure via
dictConfig, but in such a way that an alternative approach can be
easily substituted For most usages, changes to the LOGGING dict would
do exactly what Russ is talking about, but for more esoteric cases,
you'd just replace the contents of init_logging() with whatever you
wanted.
>
> I think primarily the first goal should be with the logging stuff to
> do like Russ detailed, and replicate the current functionality of the
> exception handling and admin emails.
>
I don't disagree with this - apart from the xxx_CALLBACK hooks, the
other stuff I added to Django was to illustrate how things might look
further down the line. I also think there's a case for adding logging
to some of the exception handling stuff, e.g.
handle_uncaught_exception. It's not really a lot of work, since I've
already done some of it ;-)
> I'd also be curious as to if you guys think it would be a good idea to
> integrate the messages framework with python logging. It seems like
> it follows a similar paradigm, though there might be some snaffu's
> with trying to get access to the request object in a handler/logger.
>
Personally I don't think it's worth it - they are IMO separate
concerns. Changing logging configurations should certainly not affect
the program's behaviour, for example.
> And though we've been showing mostly complex fancy examples to demo
> the power of the dictconfig stuff ... you can actually make really
> simple concise configurations as well.
>
> ie:
>
> config = {
> 'handlers':{'stream':{'level':'DEBUG',
> 'class':'logging.StreamHandler',},
> },
> 'loggers':{
> 'django':{'handlers':['stream']},
> }
>
> }
Yes, something like that is a fairly minimal configuration, but
generally I've found a file-based log to be pretty much part of every
site's requirement, for anything but the smallest (toy) site.
> My current branch of django-experimental has a working implementation
> of the exception handling and query logging (lifted from simon's
> initial proposal).
>
Likewise in my Launchpad branch, though a little different in the
details from Simon's, though the effect is much the same.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
