Support for env/config file hierarchy about argparse HOT 7 CLOSED

I like the idea in general. I'm mildly concerned about adding a ton of new 
attributes
to action objects, but it's probably worth it.

I'm still debating how much it makes sense to commit to ConfigParser as the one 
and
only configuration file format. I would be nice if the API was designed in such 
a way
that if someone wanted to add support for, say, configobj files [1], it 
wouldn't be
too difficult to do. Maybe if the API were something like::

    parser.add_argument(..., cfg_name=['Properties', 'author'], ...)

and then within argparse we do something like::

    _cfg.get(*cfg_name)

then all you have to supply as a configuration object is something with a .get()
method...? To support configobj, then you'd have to write a wrapper something 
like
(untested)::

    class ConfigObjWrapper(object):
        def __init__(self, configobj):
            self.configobj = configobj
        def get(self, *names):
            value = self.configobj
            for name in names:
                value = value[name]
            return value

That may still be a little verbose... I'll have to think about it.

[1] http://www.voidspace.org.uk/python/configobj.html#the-config-file-format

Thanks for your response.

I think cfg_name being a list is a little less intuitive/discoverable.  But I 
could 
live with it.

(Note that your wrapper idea would probably work for people who like xml..., 
they 
could write a wrapper around an xpath query)

Re: configobj, perhaps we should ask Michael if he would be willing to add a 
.get 
method to configobj.

updated patch.  refactored 2 methods:

  * _get_from_env
  * _get_from_config_file

Also fixed a bug with test_no_help (__main__.TestOptionalsHelpVersionActions)

Users who want to support non ConfigParsers can override the 
_get_from_config_file
method 

Updated patch. 

  * Removed cfg_section, and made cfg_name a list as suggested
  * Updated some docstrings
  * make get_from_config_file public (so people will subclass it for other config
file types)

Is this really the correct approach for argparse? My gut instinct is that 
argparse 
should provide one additional method, something like load_from_dict() which 
external 
applications will provide data to.

Argparse should absolutely not be involved in calculating these kind of 
env/config 
hierarchies itself, in my opinion.

I would like to do something like this with sanescript [1], for which I already 
use 
argparse, but am having some problems, because even while overriding 
error()/exit() 
control flow is broken, and so I can't then update information from.

I am nto sure if that is the same bug, or a different one

[1] http://bitbucket.org/aafshar/sanescript-main/overview/

I'm closing this as WontFix because of the lack of consensus. Basically the 
proposals were:

* Have add_argument accept some additional parameters to indicate corresponding 
config file names and environment variables.

* Add a method like "load_from_dict" that would allow such loading to be done 
explicitly.

The former will complicate the already complicated add_argument parameters, 
while the latter probably isn't much better than calling set_defaults before 
parsing.

Despite the fact that I'm closing this issue, in general I'd like to make it 
easier to support something like this. If anyone here would like to make 
another suggested API, please file a new bug at bugs.python.org (where argparse 
development has moved).

The configargparse module (now live on PyPI) extends argparse and adds support 
for config files and environment vars using approach #1 in steven.b's comment.