Vinay Sajip wrote:
> Actually you don't need much in settings.py, and Django doesn't need
> to grow any code of its own to "wrap" logging. You can either
> configure logging programmatically (for which I use basicConfig, in
> simple setups) or using a configuration file (ConfigParser-based,
> fully documented in Python docs) for more complex setups.
Thanks! Didn't know that. However see my further comment.
>> Now we've settled on a WatchedFileHandler ported from Python 2.6 logging
>> module. It watches for file descriptor change and doesn't require
>> SIG_HUP to pick up a new file. May be we should port it to Django and
>> use it as a default handler for logging to file system.
>
> Why "port it to Django"? Do you mean, copy it into Django? I'm not
> sure it should be the default - not everybody uses logrotate. I'd
> leave this sort of decision for code in settings.py.
Using WatchedFileHandler is a safe default because it works as
FileHandler, just doesn't break with logrotate. I don't know of any
disadvantages of WatchedFileHandler before the old FileHandler. So I
don't think there's much value in giving people this choice in settings
because non-default behavior will be rare (and still possible anyway).
One of the reasons why I propose Django's own settings structure for
logging is because we can choose better defaults for logging and have
more compact syntax for them. Standard Python logging configuration has
a noticable gap between very simplistic basicConfig which configures
only a root channel and a verbose imperative definition of handler
objects, formatter objects and logger objects. I've found that my usage
of logging inevitably falls in between: I often need a few logging
channels but I almost never, say, reuse handler objects between them.
Here's a variant of a simple config that I had in mind lately:
LOGGING = {
'errors': {
'handler': 'django.logging.FileLogger', # WatchedFileLogger copy
'filename': '...',
'level': 'debug',
},
'maintenance': {
'handler': 'logging.handlers.HTTPHandler',
'host': '...',
'url': '....',
'format': '....'
},
}
Top-level keys are logger names. Values are dicts describing handlers.
These dicts have several keys that Django knows about:
- 'handler': a handler class. It's imported like any other stringified
classes in settings
- 'level': a level keyword that is translated into logging.* constants.
This is done to not make users import logging by hand.
- 'format': a format string for the logging.Formatter object. We can
have a more sensible default for this than the one in Python logging. Or
not :-)
These keys are pop'd out of the dict and the rest is used as **kwargs to
the handler class instantiation.
Django's default setup may look like this:
LOGGING = {
'': {'handler': 'logging.StreamHandler'}
}
This has an advantage of always configuring a root logger to avoid an
infamous warning from Python logging when the logger doesn't have any
handlers defined. Users wanting to configure all the logging themselves
may null-out this using `LOGGING = {}`.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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
-~----------~----~----~----~------~----~------~--~---
