- Why is your example logger named d? It might seem nitpicky but it's hard
to read an example with a meaningless single character variable.
- "d.close() # stop logging" - what is this? What does it mean to "stop
logging" and why do I want to?
- "Add a coroutine" - I would wager the lay Python developer doesn't even
know what this word means.
- lggr.Lggr() - Why not just name the class Logger?
- The default format variables are inconsistent about when words are
separated with an underscore.
- I can't make sense of the example logging calls. In one you pass a
dictionary as the second argument, in another you pass three strings as
separate arguments. Why would anyone pass a message like this instead of
just using standard string formatting? Especially when there's other
legit arguments like extra. It's not even really clear why you'd want to
pass something in extra instead of in the message.
I fully support your goal, but at a glance this seems like a confusing alternative
to logging.
EDIT: hot dang it's hard to format a bulleted list on HN
> Why is your example logger named d? It might seem nitpicky but
> it's hard to read an example with a meaningless single character variable.
No particular reason -- you're right, I will change this now.
> "d.close() # stop logging" - what is this? What does it mean to "stop logging"
> and why do I want to?
This is a way to "close" the logger and clean up all of its associated coroutines. An example of when you might want to is upon catching a fatal error to your program, you might want to log the error and then safely clean up all open files or network sockets to which the logger is writing.
The method name is clearly confusing -- what do you think of using "shutdown" instead?
> "Add a coroutine" - I would wager the lay Python developer doesn't
> even know what this word means.
Maybe not, but they should! The readme now includes a link to dabeaz's coroutines page, and I'll add a quick overview in a couple of minutes.
> lggr.Lggr() - Why not just name the class Logger?
For consistency's sake. Maybe if I had to start again I would call the project `logger`, but I decided to be "hip" and use a vowel-less name instead :)
> The default format variables are inconsistent about when words are separated
> with an underscore.
The initial idea was to mimic the variable names from the default logging module (http://docs.python.org/2/library/logging.html#logrecord-attr...). You're right that it is confusing though! I think I will rename everything to be lower case, one word, instead of the default module's mix of camelCase and underscore_separated names. Thoughts?
> I can't make sense of the example logging calls. In one you pass a
> dictionary as the second argument, in another you pass three strings
> as separate arguments. Why would anyone pass a message like this
> instead of just using standard string formatting? Especially when
> there's other legit arguments like extra. It's not even really clear
> why you'd want to pass something in extra instead of in the message.
I should definitely clarify what formats are allowed and aren't. The log message format is using standard string formatting -- string.format(), to be exact. The 'extra' argument is a result of trying to imitate the default library (see http://docs.python.org/2/library/logging.html#logging.Logger... for a description of the 'extra' kwarg), and can be useful when you'd like to pass information to every single log message.
I am fairly sure that most of the streams and sockets would get closed when the interpreter exited regardless.
Also, in accordance to the principle of "explicit is better than implicit," it's generally better to avoid messing with global state (such as atexit) behind the scenes, and to provide a way to shut down the logs manually.
EDIT: hot dang it's hard to format a bulleted list on HN