ConfigParser.get() defaults?

[Tim Chase]

On 05/07/2010 07:56 PM, Steven D'Aprano wrote:
> On Fri, 07 May 2010 15:05:53 -0500, Tim Chase wrote:
>> With a normal dictionary, I can specify a default fallback value in the
>> event the requested key isn't present:
> [...]
>> However, with the ConfigParser object, there doesn't seem to be any way
>> to do a similar
>
> Sounds like a nice feature to have. When you submit a patch (*grin*),

I'm game to create and provide a patch, though I've had no 
success in the past trying to push tweaks into the Python Core 
(adding a subclass of optparse.HelpFormatter that respects 
newlines for text-wrapping).

But if there's a straightforward way to do this, I'd love to 
patch the file and submit the deltas.  I just need to know

- what sort of patch (unified diff, context diff, ed)

- against which version?  I'm currently running the 2.5 that 
Debian Testing defaults to, though I have 2.6 available through 
my repository.

- any tests needed/expected?  run how?  internal as an "if 
__name__ == '__main__'" block, or an external test suite?

- where (or to whom) to I submit the patch (and possibly tests)


I asked these questions about my optparse patch and never heard 
anything back (it was against 2.4 so I'm sure optparse has 
changed enough to render my past patches somewhat defunct)

> please make sure the caller can specify what to do on missing section and
> missing option independently.

Could you detail what you envision here?  For my use case, it's 
that the option doesn't exist, whether because there's no 
section, or there's a section but no option.  Either way, 
something failed and I want a default value back.  I don't have a 
mental model of what you expect in the "section exists but no 
option" that would behave differently from the "section doesn't 
exist" case.

Do you also have suggestions for how it should interact with the 
weird [DEFAULT] section oddities (that don't really seem to 
default the way I expect them to)?

Perhaps the two interrelate?

>> I've thumbed through the source to ConfigParser.py but don't see any
>> indication that it's possible to do what I'd like short of wrapping all
>> my cp.get*() calls in try/except blocks or creating a forked version of
>> ConfigParser.py locally.  Is there anything I'm missing, or a better
>> workaround to this?
>
> Don't fork the source code, that's ridiculously overkill. Subclass
> ConfigParser and add the required functionality.

Sorry for such loaded terms -- my "forking" suggestion wasn't 
intended to be Python, the Tim Version(tm), but rather, "copy the 
ConfigParser.py into my project directory, make the edits I 
need/want, and have it available to my project" (something 
similar to what I did for one of my projects copying in the 
python2.6 zipfile.py to my python2.4 code-base to supersede the 
standard 2.4 library's zipfile.py).

Ideally, I'd tweak the base RawConfigParser class (and its 
subclasses if needed) rather than subclass, as it's functionality 
that would be useful in all cases (Raw, regular, and Safe).

But yes, doing this would allow me to proffer the above-suggested 
patches.

Thanks for your input,

-tkc