[unshift]

your library has no tests! it's a good effort but I honestly wouldn't use it yet.

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.

[peter_l_downs]

    > your library has no tests! it's a good effort but I
    > honestly wouldn't use it yet.

You're right, and I'd love to have you help me add them!

    > i can't imagine a scenario where i'd want my logger to
    > close stdout (or any other file descriptor) for me.

By default it won't -- see https://github.com/peterldowns/lggr/blob/master/lggr/__init_....

    > 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.

Lggr will fail silently by default, because your logging library shouldn't cause your code to crash. If you'd like, it's quite easy to stop it from suppressing errors. For more complex error handling, I think users should write their own coroutines for handling log messages -- the default file printing and network sending coroutines are merely the most basic case.

    > also your SMTP and Gmail loggers don't form valid MIME messages
    > (I can't log non-ascii?).

Please help me and add loggers that do format valid MIME message! The included loggers/coroutines are just a few examples I came up with, but I'd love if other people were to contribute more :)

    > keep at it though, the logging module's API (inspired by log4j)
    > is fairly painful.

Thank you, and thanks for your feedback :)