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/SOCHCQRUNGZE5JH5CE5X4577TXSS3OOU/
Code of Conduct: http://python.org/psf/codeofconduct/