Graham Dumpleton wrote:
The strange stuff with sys.modules stuff was to protect against any problems that can occur if people decided to take the sample code and put it straight in their document tree somewhere where it could be reloaded. You'll have to trust me that module reloading can cause some nasty and hard to find problems. :-)
Yeah, I know too well the complications of managing imports. What I was really referring to though is what you hit on with this:
As to providing "handler()" this is again because it is a separate sample distinct from mod_python. If a part of mod_python that can all be done transparently. I didn't want to provide a sample where people had to hack on their mod_python installation to try it.
It seems like there should be a simpler mechanism to be able to use this code without using a separate, second handler. That's confusing to the unitiated. I guess I like the idea of providing a way for you to intialize the logging in your handler code rather than relying on another handler to do it, even though your way makes it somewhat automagic. I prefer things being explicit and simply understood rather than a "just set it up that way to make it work" explanation.
In my world, I'd rather see a call to logging.info, for example, raise an exception because I didn't tell it what req to use in some sort of initialization code. I don't think that's altogether unreasonable to ask of the user if they want to use the logging module. Obviously, since my sample implementation worked that way :) But just purely my opinion.
Not knocking your code -- I think it accomplishes what you set out to do and does it well. I'd just like to see it done in such a way that is more easily understood by noobs (and subsequently leads to fewer support requests on the list) :)
Nick
