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 -~----------~----~----~----~------~----~------~--~---