On Sun, Jun 20, 2010 at 4:59 AM, David North <david-django-develop...@dnorth.net> wrote: > On 28/05/2010 16:48, Russell Keith-Magee wrote: >> >> The second commit will be the addition of actual logging. The >> intention here is to be initially conservative; two immediate targets >> would be to replace calls to mail_admins() with logging calls, and >> replacing debug messages in management commands with their logging >> equivalent. >> >> At this point, it largely becomes a political problem -- we don't want >> Django's core to get bogged down in trivial logging calls, so we need >> to develop our policy on when we add a logging statement to trunk, and >> at what trace level, and so on. > > How about not adding any logging statements to trunk directly at all? Static > logging is in some ways bad: > > * There's no central control over the formatting of log statements
Yes, there is. Read up on the way formatters work in Python's logging library - the formatter that is used is defined centrally, and independently of the individual logging actions. See the docs on Python logging [1] and PEP391 [2] for more details. [1] http://docs.python.org/library/logging.html [2] http://www.python.org/dev/peps/pep-0391/ > * They have to be sprinkled all over the place (or in a lot of places, at > least) rather than the logging aspect of the application being more > centrally defined, which makes it hard to ensure they're consistently where > they ought to be Well.. logging is *always* going to be sprinkled all over the place - at some point, you have to be able to say "after you wibble the doo-gadget, write X to the log", and the only sensible place to this is somewhere in doo_gadget.wibble(). > One way round this is to use an aspect-oriented approach, which is nice and > easy in Python - e.g. http://www.hackersinshape.net/archives/67 - this would > allow us to drop decorators onto functions we want logging around, and > possibly even do so dynamically for maximum flexibility and ease of > maintenance. I can see how aspect orientation is an alternative approach to the central control problem, but I really don't see how it fixes the 'sprinkling' problem - instead of logging calls sprinkled everywhere, you have metaclasses that automatically sprinkle decorators on methods. This gives you less fidelity (since you can only log at the enter/exit method level), and adds magic (since you need to understand how the metaclass is works in order to understand what is being logged). > Of course, the end result would still be calls to the standard logging > framework, so this suggestion is entirely orthogonal to the rest of the > proposal. Agreed. For that reason alone, I'd rather leave it out of this phase of logging support. If you find this approach helpful, there's nothing in what is being proposed that will stop you from using it. Yours, Russ Magee %-) -- 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.
