On Tue, Sep 29, 2009 at 5:09 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > > On Sep 17, 3:04 pm, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: >> In the absence of specifics, this makes me a little bit nervous. The >> Python logging interface may be very Java-heavy and complex, but it is >> a thoroughly known quantity, and it houses a lot of features. > > See my comment about Java-heavy being FUD in Simon's initial post.
First off - let me reinforce that I'm in your camp here - I like Python's logger, and I think we should be adding logging to Django. Any hesitation I have expressed is mostly a function of institutional inertia, especially with regards to Adrian's historical position on logging. However, I would point out that IMHO, FUD is an accurate description of the state of play - though probably not in the way you probably meant. Python's logging api _looks_ a lot like log4j in parts. This is at least partially because there's a limit to how many ways you can express 'log.debug()' before you start to copy. However, as a result, there's a lot of Fear, Uncertainty and Doubt as to whether a framework that apparently has Java heritage is going to be any good in Python. Don't forget that a lot of us (myself included) got into writing Python to get away from the stupidities of the Java world. Those scars are deep, and aren't going away in a hurry. Speaking personally, log4j is responsible for a lot of those scars, due in no small part to the abysmal documentation for that project. >> I'm also not entirely convinced that the answer here isn't just >> documentation. The documentation for log4j has historically been >> pretty awful, and while Python's documentation is an improvement, it >> could certainly be better IMHO. Good documentation for how to use >> logging in the context of Django could go a long way. >> > > I'm working with Doug Hellmann (PyMOTW) to try and improve the layout > of the logging documentation in Python. I'm not asking for patches > (though it would be nice), but if you can give *specific* criticisms > (e.g. what you think is missing, or unclear) then that will focus our > efforts. My comment was actually directed at Django's documentation, which is currently silent on the issue of logging - and probably shouldn't be. However, since you're interested in feedback, my suggestion would be to look at every defense you've made of logging in this thread (and any other threads where you've had similar arguments), and work out why the current docs have allowed those viewpoints to be established as apparent fact. Some examples: * Acknowledge that there is some Java heritage, but point out that this doesn't mean it's a bad thing, and that there is a lot that _isn't_ Java based about Python's logger. * Highlight the important architectural picture. As you noted in another reply - the logger and the handler are quite separate, and this gives a lot of power. However, the existence and significance of that architectural separation isn't really a major feature of the current docs. At present, the architectural bits are buried inside API discussion, but understanding this architecture is important if you're going to understand why logging works the way it does, and understand that logging isn't just putting lines into a file. * Make the simple example actually simple. IMHO, a single-file simple logging example is good for exactly 2 things: - showing how to configure the simplest possible case of logging - explaining the "why don't I have any output" problem. Tasks like configuring the logger to use a rotating file handler are important, but can wait for much later - once issues of basic usage and architecture have been established. * Better examples of how logging works in the real world. All the examples focus on single file projects. Most of the complexities I've had with logging stem from how to use it in a multiple-file project, yet as far as I can make out, there is very little discussion of how logging should be used in a real multiple-file project. - Should I have one logger instance per module? One per conceptual "task"? - You've used "logging.getLogger(__name__)" in this thread, but this pattern isn't mentioned once in the docs. Is this best practice, or a quick-and-dirty hack? - When I have multiple loggers across multiple files, how do I configure logging? Should I be putting logging.config.fileConfig() at the start of every python file, or should I put the logging config into a single python file somewhere that configures logging, and import that module as needed? >> Details notwithstanding, I'm +1 to the idea of adding logging to the >> core framework - or, at least, making it easier to use logs for >> reporting internal state and error conditions instead of email). >> > > You can have your cake and eat it. It's perfectly feasible in Python > logging to send only certain events to nominated email addresses (all > configurable at run-time, so emails can be turned on/off, sent to > different/additional destinations etc.) as well as e.g. logging > tracebacks to file for the same events. Agreed. >> As for likely roadblocks: I've been led to believe that Adrian has >> objections to framework-level logging. I have no idea as to the nature >> of his objection, but ticket #5415 indicates that he is (or has been, >> historically) in favor of adding signals that could be used for >> logging or debugging purposes. >> > > They (logging and signals) are two different things. Python logging > allows you to consider the dimensions "What happened?", "Where did it > happen?", "How important is it?" and "Who wants to know?" > intelligently, and in particular it treats "What happened" and "Who > wants to know?" orthogonally. You get a lot of ways of getting > information to *people* whereas signals is more about letting *code* > know what's going on. Granted, although the two aren't mutually exclusive. After all, the way you let someone know "what happened" is with code; It isn't hard to think of a setup where we emit a signal everywhere that we might want to log, and then attach a logging signal handler to those signal. I'm not suggesting that this would be a good architecture - merely a possible one. > Unfortunately, a lot of people have got the impression that Python > logging is "Java-like" and "not Pythonic" just because I acknowledged > some good ideas in log4j. It's not as if Python people have a monopoly > on good ideas, is it? This "Java heritage" perception sometimes leads > to prejudice against logging, for no good reason that I can see. An idea isn't bad just because it comes from the Java world, but in fairness - the Java world does have a history of producing some pretty dumb ideas. "Based on a Java API" isn't generally a complement in the Python world :-) I understand entirely the frustration of having a project perceived "the wrong way" by the public - Django Evolution has been stuck with a "magic" moniker for reasons that I can't begin to fathom. However, at the end of the day, you can't blame the community for their perceptions. One or two people might accidentally misunderstand something, but when it starts happening systemically, you need to start looking inward for the cause. > Of > course there might be grievances - for example, people complain about > "slow". As a single logging call which just has a file handler is of > the order of some tens of microseconds, I don't know how bad this is - > what do we compare against? The Tornado webserver (used by FriendFeed) > is a high-performance solution which uses Python logging. SQLAlchemy > uses Python logging. They are careful to consider performance and as a > consequence logging doesn't present a problem in practice. For the record, speed actually isn't one of my major concerns. 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-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 -~----------~----~----~----~------~----~------~--~---
