Marc Abramowitz added the comment:
Well my thought is that the configuration file has defaults that a user may
want to override at runtime using an environment variable or command-line
switch.
I guess as SilentGhost pointed out, maybe this is not the responsibility of the
ConfigParser as
Łukasz Langa added the comment:
Having both `defaults` and `overrides` would confuse the API, especially given
that we already have `fallback` arguments to `get*` methods.
What's the point of having overrides *over* a file? Defaults were thought of as
a way to say: "unless the user bothered
Marc Abramowitz added the comment:
So I think changing the behavior of `defaults` might break backwards
compatibility for folks who are relying on the old behavior.
So I guess I would propose adding a new parameter called `overrides`. These
would take precedence over `defaults` and that
Marc Abramowitz added the comment:
Some more info on the logging example I gave.
So here is a program called `my_app.py`:
```
import os
import logging.config
logging.config.fileConfig('logging.ini', defaults=os.environ)
logger = logging.getLogger(__name__)
logger.debug('debug msg')
SilentGhost added the comment:
You can override the level if an environmental variable was defined. Not sure
why it needs to be responsibility of the ConfigParser.
While I'm not going to immediately close this issue, I don't think such a
backward-incompatible proposal is viable.
--
New submission from Marc Abramowitz:
My expectation was that any defaults I passed to ConfigParser when creating one
would override values in the DEFAULT section of the config file. This is
because I'd like the DEFAULT section to have the default values, but then I
want to be able to override
