ConfigParser.get() defaults?

[Tim Chase]

On 05/08/2010 01:58 PM, Steven D'Aprano wrote:
> If your patch doesn't attract the interest of a Python-Dev
> developer, you might need to give them a prod occasionally.
> Their time for reviewing bugs and patches is always in short
> supply.
>
>> - where (or to whom) to I submit the patch (and possibly
>> tests)
>
> Submit the patch and tests to the bug tracker at
> http://bugs.python.org/

Okay -- a good first stop, and vastly more helpful than the 
non-reply I got regarding my optparse patch.

>> - any tests needed/expected?  run how?  internal as an "if
>> __name__ == '__main__'" block, or an external test suite?
>>
> Look at the tests in (e.g.) /usr/local/lib/python2.6/test/ for
> an idea of what you should do.

I poked in my Debian analogue (/usr/bin/lib/python2.6/test/) but 
the tests there seemed a bit...um...lacking?  There was nothing 
testing ConfigParser at all, just three high-level test modules. 
  Granted, I could create some tests that exercise my code, and 
perhaps some that should have been there in the first place, but 
that's a big jump from merely adding a couple tests (non)existing 
ConfigParser tests.

> Because this is a new feature, and 2.5 (and 2.6?) are in bug fix only
> mode, you should probably aim for 2.7 or 3.2 as the ideal. Patches
> written against 2.6 or 3.1 are probably good enough though.

Okay, I've submitted the patch to dev.python.org in the hopes 
something comes of it, even if it's 2.7 or 3.2

> That's what I thought you meant. Forking is the right term in this case
> (you are forking the ConfigParser module, not all of Python), and I still
> say it is overkill. Generally speaking, when a module doesn't do what you
> want, and modifying it isn't an option, there are five things you can do.
> In order of decreasing desirability:
>
> (1) Write a small wrapper function to tweak the behaviour.
>
> (2) Sub-class the class to gain new behaviour.
>
> (3) Monkey-patch the module at runtime.
>
> (4) Fork the module and modify that.
>
> (5) Re-write the whole thing from scratch.

I'd say the ordering of your #3 and #4 are more ambiguous -- if 
I'm distributing/deploying a project and my monkey-patching gets 
broken (there's a reason monkey-patching feels dirty) by some 
python lib upgrade external to my control, then I & my code look 
bad.  If I freeze a modified/locally-forked library module, it 
continues to work regardless of the environment.  Maybe that's an 
indicator that I did a bad job of monkey patching, but I prefer 
to prevent breakage where I can.

-tkc