On Sep 29, 2:25 pm, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
>
> 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).
>
It's similar to Django's support for, say, simplejson. I think it's
reasonable for Django to alias WatchedFileHandler so that it's
available either bound to logging's own implementation (in
sufficiently recent versions of Python) or else a copy in Django's own
code. Then people can use it if they want to, even in older Python
versions.
> 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 = {}`.
I have no big problem with a configuration scheme such as you suggest
- if it's felt that a lot of Django users are not Python-savvy enough
and need some hand-holding, then you'd perhaps need something like
this. I usually configure the logging system using its own
configuration file format (ConfigParser based, and supported by the
stdlib so no additional Django code required) or using YAML (where
it's already being used for other configuration, and when having a
PyYAML dependency is not a problem.) Either way it's declarative and
not too painful. My reservation with Django's own take on it is simply
that it goes against TOOWTDI and the Zen of Python, a little at least.
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-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
-~----------~----~----~----~------~----~------~--~---
