Slightly off topic: in an effort to become a better programmer, and to improve the Python ecosystem, I've tried to write a "for Humans" style logging library. Would anyone mind giving me feedback?
- 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.
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.
> "d.close() # stop logging" - what is this? What does it mean to "stop logging"
> and why do I want to?
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.
> 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.
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.
* Leave blank lines between bullet points,
* Start each line with <splat> <space>
* Bob's your parent's brother.
Hope that helps. See also:
a few nit picks: i can't imagine a scenario where i'd want my logger to close stdout (or any other file descriptor) for me.
there is a lot of missing error handling, which is really important for something critical like a logger. what happens when disk space runs out? no timeouts on network operations?
also your SMTP and Gmail loggers don't form valid MIME messages (I can't log non-ascii?). you also seem to just swallow exceptions which is totally not what I would want or expect from a logging library.
keep at it though, the logging module's API (inspired by log4j) is fairly painful.
> your library has no tests! it's a good effort but I
> honestly wouldn't use it yet.
> i can't imagine a scenario where i'd want my logger to
> close stdout (or any other file descriptor) for me.
> there is a lot of missing error handling, which is really
> important for something critical like a logger. what
> happens when disk space runs out? no timeouts on
> network operations?
> [...]
> you also seem to just swallow exceptions which is totally
> not what I would want or expect from a logging library.
> also your SMTP and Gmail loggers don't form valid MIME messages
> (I can't log non-ascii?).
> keep at it though, the logging module's API (inspired by log4j)
> is fairly painful.
A big feature missing, IMHO, is file-based configuration. You definitely want this for larger projects.
d.critical("Someone {} us {} the {}!", "set", "up", "bomb")