One thing I just don’t understand is why more people, especially framework designers, omit or skip logging. Django appears to, which is incredibly annoying to me. It is a complex framework, which makes all kinds of assumptions and relies on convention to infer a lot of functionality. That’s great, but being able to “turn up” the log-level and see some discussion about what decisions it is making, based on what criteria it is using would be incredibly valuable to me. Not only to me, I wager, but to everyone who is learning the framework, or who is teasing out a difficult bug. Yet going in and adding framework-level logging is almost impossible, even on an open-source project, since your changes will not be accepted and will quickly become a merge nightmare.
Don’t believe me about changes “not being accepted”? Here’s proof. (That’s not my bug, by the way, just proof). The developers closed the ticket saying they “fail to see what this gains Django”. Foolish and shortsighted.
Logging is preferred by most senior programmers over line-by-line code stepping. It is both more efficient, and allows for post-mortem analysis of problems in a way that debuggers never will. Yet many act as if it is a nice-to-have, or worse an irrelevant distraction.
Shortsightedness is deadly
I once worked on a team with a programmer who refused to add any logging to a super-awesome-framework he’d written for Java. Evidently the framework was the solution to everything we needed. I challenged him in a team-meeting about his refusal, talking about the numerous benefits of good logging throughout a system. He replied “I don’t write bugs, so I don’t need to waste time logging to find them”. I had him fired, and good riddance, within a week. Attitudes like that have no place on a software team. It was his foolish assertion that he didn’t write bugs that was the final nail, but his refusal to see the benefits of logging certainly didn’t help his case any.
Logging is built-in to Python, and is a commonly available module for Java. It is high time to make this practice part of generally accepted programming standards for frameworks. Don’t want a log? Turn it off. But you should always be able to get one. Always.
Technorati Tags: logging, java, python, django, rants
6 responses so far ↓
1 Jacob Kaplan-Moss // Jan 19, 2006 at 11:19 am
The reason that we haven’t included a logging framework in Django is that Python already *has* a logging framework — and a pretty good one, at that (see http://docs.python.org/lib/module-logging.html).
It seems dumb to spend out time writing something that’s part of the standard library — we wouldn’t spend time writing our own XML parser; why write a logging framework?
[BTW, your comment-spam protection on this blog is positively draconian. It kinda sucks I need to log in AND complete a CAPTCHA (one that’s gotta suck for non-native English speakers to boot) just to respond to you. You might want to consider lowering WordPress’ parinoia meter :)]
2 import this. » Blog Archive » Django and framework logging // Jan 19, 2006 at 5:19 pm
[…] Quoth Bruce Kroeze: One thing I just don’t understand is why more people, especially framework designers, omit or skip logging. Django appears to, which is incredibly annoying to me. It is a complex framework, which makes all kinds of assumptions and relies on convention to infer a lot of functionality. That’s great, but being able to “turn up” the log-level and see some discussion about what decisions it is making, based on what criteria it is using would be incredibly valuable to me. Not only to me, I wager, but to everyone who is learning the framework, or who is teasing out a difficult bug. Yet going in and adding framework-level logging is almost impossible, even on an open-source project, since your changes will not be accepted and will quickly become a merge nightmare. […]
3 Administrator // Jan 19, 2006 at 5:54 pm
(thanks for the note about the paranoia level, I removed the registration requirement)
I also don’t want Django to have its own logging. I want it to use Python’s standard logging throughout the code. That is, it should be doing something like
log.debug(”Resolved incoming url %s to module %s, sending to that module.” % (url, module))”
inside the base Django framework code itself. The fact that it does not is a weakness, in my strongly-stated-opinion.
4 Bruce // Jan 19, 2006 at 6:16 pm
If the Django project would accept the patch (after review, of course), I would be happy to write the logging code I mention. I could do it “very light”, so that it would cost next-to-no cycles when logging is turned off. I’m just not going to bother until I know that I won’t be wasting my time with something that’ll be rejected anyway.
5 James Bennett // Mar 31, 2007 at 5:41 pm
This really feels like something where we wouldn’t be able to please everyone — no matter how “light” it is, it still involves overhead in terms of code size and maintenance, and all to save someone from having to type “import logging” on their own
Keep in mind that everybody’s going to have different things they want to log — you might want to log every time a URL is resolved, Alice might want to log every time a model is instantiated, Bob might want to log every time he renders a template, and so on. Supporting that directly in Django would mean either littering the code with direct calls which log according to settings, or littering the code with dispatcher signals which would be picked up by a logging handler. Neither of those is a happy situation — again, code weight increases, extra runtime overhead is introduced, maintenance gets harder, and it probably wouldn’t cover everything everyone could want without going to extremes.
Meanwhile, if you need to track something, it’s still fairly easy to add logging code directly where you need it, and then take it out again when you don’t need the logging anymore. Everybody wins that way — Django doesn’t have to grow tons of code to support logging, and people who want to log have the option
6 Vinay Sajip // Apr 8, 2007 at 4:01 am
James: It’s a pain to do this when you are using the development version and regularly doing svn updates to get the latest good stuff. For example: I’m doing a migration of legacy data into a Django app, and I get occasional constraint errors from the DB. So I want to log the SQL being executed in order to be able to pin down the problems. With your approach, wouldn’t I have to reinsert edits I made to add logging to the framework every time I did an “svn up”? It’s hardly ideal.