On Mon, Aug 24, 2020 at 7:39 PM Adam Hendry <adam.grant.hen...@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.hen...@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-id...@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-le...@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/SOCHCQRUNGZE5JH5CE5X4577TXSS3OOU/ >>> 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
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/CZWMJ5TPCX3HP5YMCWXH26CE433XSCXH/ Code of Conduct: http://python.org/psf/codeofconduct/
