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.
>
> I've seen several attempts to wrap Java loggers in a "nicer"
> interface, and every one of them ended up hobbling some of the power
> features of the logger. There is also the issue of our wrapper playing
> nicely with the loggers already being used in the wild.
>
Absolutely agree. Wrapping is the wrong way to go, and not even
needed. I use logging with Django all the time and see no need to have
any special code in Django to support logging. Where necessary, I've
patched my Django to include logging statements.
> 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.
>
> 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.
> 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.
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. 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.
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
-~----------~----~----~----~------~----~------~--~---
