On Mon, Aug 24, 2020 at 7:39 PM Adam Hendry <adam.grant.hendry@gmail.com> wrote:
In the spirit of CHB's recommendation, this is my proposal:
Would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib?
These look like good ideas to me. And whether or not it would be considered for the stdlib, a nice package on pypi could be nice. So I encourage you to work on this :-) After, of course, looking and seeing what's already out there. (though a quick search in PyPi turns up, surprisingly, nothing. Lots of packages that have to do with logging, but nothing that looks like a Pythonic API -- at least not anything that looks the least bit documented or maintained. -CHB
- Use properties and magic methods instead of getter and setter methods - Add flag tfor `sys.excepthook` to choose whether to route all unhandled exceptions to the root logger - PEP8ify to make source code more readable and "pretty" - Make module-level `getLogger()` a class singleton, as it's only to be used once (warrants further discussion; I don't know if this is unnecessary) - Provide context managers for loggers to prevent race conditions (e.g. rather than `getLogger()` have `with logger(__name__)" (warrants further discussion; I don't know if this is unnecessary) - Enable iteration over all existing loggers by writing `__len__`s and `__getitems__` for logging (warrants further discussion; I don't know if this is unnecessary)
Again, these are just my thoughts. Mike Miller is right in that the `logging` module is EXTREMELY intimidating to the new user. This keeps new users from logging, which (arguably) should be done as best practice.
On Mon, Aug 24, 2020 at 7:23 PM Adam Hendry <adam.grant.hendry@gmail.com> wrote:
Hello Everyone,
Uh-oh, I think you misunderstood me. I was trying to be funny. Raymond always does his "fist-slamming" thing in a funny way, so I was trying to emulate that. I'm not mad. This is my first feature request post.
The `logging` module works, so there's nothing that needs to be fixed. Believe me, I'm a content-over-form programmer every day of the week and twice on Sunday. We could make it more Pythonic though.
One feature I would like to have added though is a flag I can set to route all unhandled exceptions to the root logger. I need this for my production GUIs, for example, and I have to override `sys.excepthook()` to get this to work right now. Not a huge problem currently, but I think this would be a nice addition to the module.
Adam
On Mon, Aug 24, 2020 at 4:43 PM Mike Miller <python-ideas@mgmiller.net> wrote:
On 2020-08-24 09:25, Christopher Barker wrote:
I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing.
Yes, many folks have. I've thought about it a bit myself.
The logging package is comprehensive, mature, *very* flexible, and Java-esque. I've come to appreciate it over the decades.
My take is that the extensive flexibility was more important in the past, the Java-feel only mildly annoying. In the spirit of batteries-included it has tons of baked-in functionality like file rotation, talking to the network, and the NT event system. Though it sometimes made sense in the past, I argue most of the functionality is not necessary to have in the stdlib today. Result:
- At the low/beginner end, the package and docs are simply overwhelming. - For the mid-size project, it duplicates functionality like the Unix logrotate and syslog programs. - At the high-end, folks have moved on to "the ELK stack" etc and hosted services. Few are using python for *everything* at a larger shop.
The "12 factor app" pattern for modern services alludes to the latter point:
https://12factor.net/logs A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.
Therefore, a simple way to log to stdout without a lot of reading and boilerplate might be useful.
This is what logging.basicConfig() was supposed to be, and it is close but doesn't quite hit the mark. The camelCase name is one small issue, it being buried under a mountain of docs is another. Needing to import constants is slightly annoying as well. It may be able to be improved doc-wise by putting it front and center on the first page of the logging docs. The TOC will still be overwhelming to the newcomer however.
Proposed solution: a trivial pythonic wrapper module with another name and page in the docs. It says something like:
log - Logging Quickstart Module =======================================
The log module is a simple interface meant to simplify logging for *applications,* rather than libraries. This distinction is important.
Libraries should be handled as they always have, and no changes are necessary to continue to use logging with them::
# hellolib.py import logging
logger = logging.getLogger(__name__)
def hello_world(): logger.info('hello world!')
For applications that simply want to log to standard out as would a modern service, initialize logging quickly with log::
# main.py import log import hellolib
log.configure() # with good defaults
hellolib.hello_world()
To configure logging and use it in the main script, a slightly more complex version might look like this::
# main.py import log import hellolib
logger = log.configure('debug', format='%(levelname)s %(message)s')
logger.info('About to call hello_world()...') hellolib.hello_world()
I've experimented a bit with a module on PyPi named "out," with similar ideas, though I probably have over-engineered it with ANSI colors and Unicode.
-Mike _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SOCHCQ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython