To do & Feature ideas 💡

[metachris]

To do:

• Documentation strategy - currently the detail docs are in RST format and hosted on readthedocs. The docs would need a refreshing, to make sure it's all up to date and everything is working as intended. Thought: maybe better as markdown docs on GitHub, so we can more easily copy code between the README and other places?

This is an incomplete (and growing) list of possible features to implement:

• Better way to define StreamHandler output (stdout, stderr, nothing)
• When using logfile with non-existent path, create it (see [RFE] - Create directory structure, if it doesn't exist #129)
• Typings
• More built-in handlers (not sure if wanted)
  • mail - see Add mail handler to error/warn log entries #71
  • TimedRotatingFileHandler(https://docs.python.org/3/library/logging.handlers.html#timedrotatingfilehandler) (see Is time rotating logging supported in logzero? #99)

---

Please comment to add more, as well as to indicate interest.

[HappyEinara]

Hey Chris, logzero is a real pleasure to use, so thank you! My suggestion is to import and expose the loglevel constants like logging.DEBUG as logzero.DEBUG. For simple applications of the kind you document, it would limit the boilerplate of having to import both logging and logzero, and make the use of logzero easier to document and understand.

There may be reasons why this is a bad idea. And certainly the current design means replacing logzero in an application is trivial, should it ever be necessary. But I think giving us the option to risk a future find-and-replace job if we need to is no big deal. Logzero is already quite opinionated (in a good way).

Of course, the constants you expose should be exactly equivalent to logging.DEBUG and co., the implementation of which seems straightforward.

In almost every project I write, this would let me do:

import logzero

logger = logzero.logger
logger.loglevel(logzero.INFO)

Which I think is nicer than

from logzero import logger
import logging

logger.loglevel(logging.INFO)

and more approachable to beginners who might not care to learn enough python to understand the wonderful logging framework stlib provides. Only logger = logzero.logger is admittedly a bit counterintuitive.

In practice, I think a tiny logging module that wraps the logging implementation and provides a basic .logger(name) function and .DEBUG etc. constants to all other modules is a good pattern that provides pluggability for all non-trivial apps. Then I can use logzero or any other solution as backing in that module.

But that then means avoiding the unnecessary import of logging just to get some constants to set the loglevel in a trivial cli that just uses logzero is all the more compelling.

[metachris]

Good idea 👍

…

On Tue, 16 Mar 2021, 04:00 Dave, ***@***.***> wrote: Hey Chris, logzero is a real pleasure to use. My suggestion is to provide import and expose the loglevel constants like logging.DEBUG as logzero.DEBUG. For simple applications of the kind you document, it would limit the boilerplate of having to import both logging and logzero. There may be reasons why this is a bad idea. And certainly the current design means replacing logzero in an application is trivial, should it ever be necessary. But I think giving us the option to risk a future find-and-replace job if we need to is no big deal. Logzero is already quite opinionated (in a good way). Of course, the constants you expose should be exactly equivalent to logging.DEBUG and co., the implementation of which seems straightforward. In almost every project I write, this would let me do: import logzero logger = logzero.logger logger.loglevel(logzero.INFO) Which I think is nicer than from logzero import logger import logging logger.loglevel(logging.INFO) and more approachable to beginners who might not care to learn enough python to understand the wonderful logging framework stlib provides. Only logger = logzero.logger is admittedly a bit counterintuitive. In practice, I think a tiny logging module that wraps the logging implementation and provides a basic .logger(name) function and .DEBUG etc. constants to all other modules is a good pattern that provides pluggability for all non-trivial apps. Then I can use logzero or any other solution as backing in that module. But that then means avoiding the unnecessary import of logging just to get some constants to set the loglevel in a trivial cli that just uses logzero is all the more compelling. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#340 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4RS3AIJL3EZLY3WL3CALTD3CURANCNFSM4STNCOOQ> .

[metachris]

Thanks @HappyEinara. Implemented in v1.7.0