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?
- 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 <[email protected]>
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 <[email protected]>
> 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 -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/[email protected]/message/SOCHCQRUNGZE5JH5CE5X4577TXSS3OOU/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/LHYWSLE6HBWEDDIVJRSRAHDD6E7WJ6MO/
Code of Conduct: http://python.org/psf/codeofconduct/
