On 17 May 2014 22:05, "Thomas Güttler" <guettli@thomas-guettler.de> wrote:

> Using logging as library works well in Python. But writing console
> scripts which use logging force the developer to solve the same
> problems again and again: How to set up the logging?
>
> And the developer of the console script does
> not know how the user of the console script wants to handle logging.
>
> That's why all Python application have a different way to set up the logging.

But this is also why command line frameworks like Cement exist (disclosure: Cement was just the first example I found of the kind of full featured CLI framework I mean. There may be other examples).

I guess my question is, if an application is to the point of worrying about configuring logging, why should we handle it in the interpreter for command line applications, when we leave it to frameworks to handle for web and GUI applications?

Application configuration is a complicated problem - you have to decide what to do about global defaults, user defaults, environment variables, command line options, potentially runtime adjustable options for daemons, SIGHUP handling, etc, etc.

This complexity, along with other questions like ini-format vs JSON vs YAML is a key part of *why* PEP 391 punted on the question and just defined logging.dictConfig() instead.

Cheers,
Nick.

>
> > For 3.2+, we defined a sensible default logging configuration (warning
> > and above written to stderr, everything else ignored), so users should
> > be free to just use the logging module when writing libraries without
> > worrying about whether or not it has been configured for reporting
> > properly. That doesn't help Python 2 users, but that's the case for a
> > lot of things.
>
>
> > Trying to provide a way to actually *configure* logging in a general
> > way would be fraught with backwards compatibility issues when it came
> > to interfering with frameworks (whether for writing CLI applications,
> > web applications, or GUI applications) that already providing their
> > own way of handling logging configuration.
>
> Of course a standard way to get the logging configuration defined by the end user
> should be optional. I don't see any backwards compatibility issues.
>
> The author of the console script should just need one line, to
> get the defaults which the console script user wants.
>
> {{{
> import argparse
>
> def main()
>     logging.config.defaultConfig()
>     argparse...
>
> }}}
>
> The end user can set up the logging in the way he wants:
>
>  - Log to a file
>  - Log to a daemon
>  - Format the messages the way he likes it
>  - ...
>
> Since I know that some logging environments are complicated, I think
> it is best to hook into a method call. There are environments
> where fileConfig() does not solve all needs.
>
> Please ask if, you don't understand what I want.
>
>
>  Thomas Güttler
>
> --
> Thomas Güttler
> http://thomas-guettler.de/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/