[Python-Dev] Using logging in the stdlib and its unit tests
Glenn Linderman
v+python at g.nevcal.com
Sat Dec 11 20:17:05 CET 2010
On 12/11/2010 3:52 AM, Vinay Sajip wrote:
> I will try to incorporate more basic examples at the top of the documentation,
> but surely you don't want me to add more verbiage about basicConfig when your
> overall feeling is that there's too much documentation?
I try not to post unless I feel there is a new detail; yes the 8% is
probably repetitive, but at present, going further, at least
sequentially, does feel like a large mountain to climb... suddenly
becoming significantly steeper there.
I really can't say much about the 92% of the documentation, because of
the mountain.
Whether the existing documentation can be reordered to avoid the steep
part, but rather provide a gentle upward path, I cannot say. If it is
properly organized reference material, then probably adding more about
something at the beginning is appropriate, to give the foundation,
justification, and assistance for climbing the slope.
My overall feeling is not necessarily that there is too much
documentation (there is a lot, but maybe that is a good thing, I should
read it some week) but that it suffers in not providing useful
information for the beginner at the front. I've listed what I've
gleaned here and tried to point out the things that I still don't know,
and tried to point out where things became less than obvious along the
way. I do think it was primarily because the intro material is too
brief and too disconnected, that I quit reading at the 8% mark (or so).
If the rest of the large document were to be similarly disconnected, it
wouldn't be worth my time to read it... and if I had to read it all,
just to understand enough to get started with simple logging, then it
would be faster to write my own, which is the path I took. I suffer
with my own being primitive, but I can tweak it when I need to. I still
don't fully understand the nuances between handlers and filters, and
likely won't until I read more of the documentation.
Jumping directly to the documentation (at the 28% mark, I'd have had to
read a long way to find it) for basicConfig per your links helps, but
sadly, because the first paragraph is full of the terms "logger",
"handler", and "formatter", which I have only rudimentary ideas about
what they do, being a beginner, I almost gave up again. But the
description of the valid keywords for **kwargs was actually
understandable, at the end of that documentation. I also learned that
calling basicConfig more than once in a program is probably useless, and
it should be nearly the first logger API called, if it is used. The
first paragraph should be split, perhaps: "Does basic configuration for
the logging system." is almost redundant with the name, but is OK if
first. The rest of that paragraph, and the next three, should probably
be moved after the list of kwargs keys and descriptions. Yes, the word
handler is used a bit, but it is associated there with concepts like
file names and stream handles, and that eases the uncertainty; together
with the simple example at the front, and the verbage there, I can see
that I specify a file name, and it makes the logger log to that file :)
And the level parameter is fine. I'm less sure about format and datefmt
and why I would want to specify them or how, and am surprised to find
that format is to be used by a "handler" not a "formatter", but the
simple example shows me I can leave those out for starters.
Personally, I suffer in writing documentation; when I attempt to do so,
and people read it, they usually tell me that after about the third
read, they finally understand it, but sadly it takes them three reads.
It is interesting to be looking at the logger from the other side...
maybe I'll be able to improve the documentation I write, after analyzing
why the logger documentation was hard for me to approach.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101211/84082181/attachment.html>
More information about the Python-Dev
mailing list