On Sep 29, 1:53 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
>
> 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.
>
That's great. I agree about adding logging to Django, and would like
to help if I can. It would be good to understand what underlies
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.
>
We're on the same page, I think. Python's similarity to log4j is, I
feel, skin deep. Just as our having features in common with monkeys
and apes doesn't *make* us monkeys and apes, so also with Python
logging and log4j. Compare and contrast: log4j is around 160 source
files and 16K SLOC, whereas Python logging is 3 source files and under
1500 SLOC! Notice the order of magnitude difference. Functionally,
Python logging pretty much provides the same functionality as log4j,
but it's a lot simpler internally. Python logging is *not* a port of
log4j, is written in as Pythonic a way as I know how (given that it
was written when it was), and got a lot of peer review from the smart
people on python-dev before going in (and got changed here and there
to satisy concerns raised during the review process). Nevertheless,
FUD (and I think I did mean it in that sense - Fear, Uncertainty and
Doubt) needs to allayed. I'll be happy to try and do this, please feel
free to ask any specific questions or make any specific criticisms and
I'll do my best to deal with them.
> My comment was actually directed at Django's documentation, which is
> currently silent on the issue of logging - and probably shouldn't be.
Right.
> 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.
>
That's easier to do when people raise specific points, rather than
talk about Java heritage in an arm-waving way, as if it's an offshoot
of the Black Death ;-)
If you want an example of Python written in the Java style, look at
Apache QPid. Python logging ain't that.
> * 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
That's because the docs are really pitched mainly as a a reference
guide.
> 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.
>
I've recently created a blog about Python logging, where I talk about
logging from first principles and try to show why the design of Python
logging is as it is. It's not perfect, but it's a start.
http://plumberjack.blogspot.com/2009/09/python-logging-101.html
> * 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.
I'm not sure what you're getting at. Sometimes, those two things is
all that people want to know at that time.
> 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.
Sure, and I hope with Doug Hellmann's input we can get the Python
logging docs to be laid out in a more logical order and imbued with
more clarity. Doug's PyMOTW series sets a high bar for documentation
quality - concise, yet clear.
> * 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.
Partly because every system is different. I agree, it can't hurt to
add some more complex examples.
> - 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?
True, it should be perhaps clarified as a best practice, but I tend to
be wary of being too prescriptive.
> - 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?
>
This is all very good feedback and I will be thinking about how to
address this in the docs.
> > 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.
>
I agree - it's possible, but perhaps not the most simple or intuitive.
If you can log something directly from where you are, why send a
signal to some other code which, while processing that signal, will
log something for you?
>
> 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 said based on their ideas, not based on their code. I didn't even
look at the log4j code when implementing Python logging. But as you
said, logger.debug("Message") is not quintessential-Java-and-a-million-
miles-from-Python.
>
> 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.
>
Agreed. People have prejudices, you just have to work away at removing
misconceptions.
>
> For the record, speed actually isn't one of my major concerns.
>
Thanks for all the feedback. It's good to get so much after a long
time in cold turkey ;-)
Regards,
Vinay Sajip
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
