Sane default for logging config

[guettli]

BPO	21495
Nosy	@terryjreedy, @vsajip, @ericsnowcurrently

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2014-05-16.19:06:22.081>
created_at = <Date 2014-05-13.13:32:56.152>
labels = ['type-feature', 'library']
title = 'Sane default for logging config'
updated_at = <Date 2014-05-18.17:15:38.919>
user = 'https://bugs.python.org/guettli'

bugs.python.org fields:

activity = <Date 2014-05-18.17:15:38.919>
actor = 'guettli'
assignee = 'none'
closed = True
closed_date = <Date 2014-05-16.19:06:22.081>
closer = 'terry.reedy'
components = ['Library (Lib)']
creation = <Date 2014-05-13.13:32:56.152>
creator = 'guettli'
dependencies = []
files = []
hgrepos = []
issue_num = 21495
keywords = []
message_count = 7.0
messages = ['218453', '218488', '218499', '218514', '218552', '218677', '218748']
nosy_count = 4.0
nosy_names = ['terry.reedy', 'vinay.sajip', 'guettli', 'eric.snow']
pr_nums = []
priority = 'normal'
resolution = 'later'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue21495'
versions = ['Python 3.5']

[guettli]

Imagine you write a small console script which is implemented like a library.

This tool has to do two things: the console script needs to configure the logging, and the library needs to use it.

The library usage of logging it easy well documented:

{{{
logger=logging.getLogger(name)
}}}

But the part in the console script has no sane default in the python world.

I know how to set up the logging config with BasicConfig, DictConfig, ...

There needs to be something like DefaultConfig() which reads its config from well known places.

This bug report is not about clever code solutions. It is about a sane and easy default agreement on how to load the logging configuration.

[vsajip]

Who decides what's sane and what isn't? You seem to be asking for something, but you don't seem to have a concrete proposal.

Are there "sane" defaults in other worlds than the Python world? What are they?

[guettli]

Thank you for reading and replying.

Yes, I wrote no concret proposal up to now.

I have this solutions in mind:

logging.config.defaultConfig()

Related https://docs.python.org/2/library/logging.config.html

Loading a python module:
------------------------

load a module "loggingconfig" this module gets imported like any other python module. It is like django loads its settings. It could be possible to check the environment variable LOGGINGCONFIG first. It could contain a string which defaults to "loggingconfig".

This module has a method "set_up()" which sets up the logging for this environment.

Loading from a file:
---------------------

A file searched in this places:

• CWD/.loggingconfig.conf
• VIRTUAL_ENV/.loggingconfig.conf
• HOME/.loggingconfig.conf
• etc/loggingconfig.conf

The file gets loaded with fileConfig()

Module or file config loading
-----------------------------

I think the module loading is better than the file based solution. That's why I think it should be done first. If there is no module found, the file loading should be tried.

If not config found
--------------------

If not config was found, default gets set.

My proposal:

• loglevel is set to INFO. (Debug gets suppressed)
• format: '%(asctime)s %(name)s: %(levelname)-8s [%(process)d] %(message)s'
• logging goes to stdout

---------------------------

What is the best way to get this into the python standard library? Should I create a PEP?

[vsajip]

Just on backward compatibility grounds, a proposal like this isn't going to be acceptable on python-dev, I believe, and I'm not even sure it's necessary to have such a thing in the stdlib: why not just use the approach you suggested for your own projects, and leave it at that? I've certainly found that preferences for configuration approaches vary a lot across people, and nothing will please everyone :-(

Generally, before writing a PEP, ideas are broached on the python-ideas mailing list, then move to the python-dev mailing list when they seem to have enough mileage to do so, and the PEP discussion / life-cycle happens there.

[ericsnowcurrently]

FWIW, I agree with Vinay.

[terryjreedy]

Moving discussion to python-ideas was the right thing to do. I am closing this for the present as there is no concrete accepted idea to write a patch for. Thomas, if that changes, you can re-open.

[guettli]

Just for the record.

Here are the discussions about this topic on the python-ideas mailing list:

https://mail.python.org/pipermail/python-ideas/2014-May/027839.html

https://mail.python.org/pipermail/python-ideas/2014-May/027858.html