Logged In: YES 
user_id=7733

Also see the python-dev thread at
<http://mail.python.org/pipermail/python-dev/2004-August/046607.html>.
The third message in the thread was garbled due to a GPG
problem; reproduced below.

[Fred L. Drake, Jr.]
> David has (properly) been asking me to look into this, and
i've
> managed not to have enough time.  Sorry, David!

I thought a python-dev nudge might get you off your keister ;-)

> The ConfigParser documentation was certainly too vague,
but the
> problem, as I see it, is that the module was never
intended to store
> non-string values.

BUT ConfigParser *did* allow non-strings to be stored, for
internal
use only (can't write them out, of course).  And changing it
*did*
break code.  I think a doc change acknowledging that ability but
qualifying it ("for internal use only, can't be used to
write out
config files or interpolate values") would have been a
better fix.

The change in rev. 1.65 makes ConfigParser.py *less* useful.
 When I
used ConfigParser in Docutils, I wasn't being especially
clever when I
used it to set non-string values.  It will take a lot more
cleverness
post-rev-1.65 to enable that functionality.

Of course, the fix to Docutils is pretty simple: just override
ConfigParser.set with the older version.  But that depends
on private
implementation details (self._defaults, self._sections). 
This is
*much* more dangerous and impossible to future-proof against.

> I think allowing them is just asking for still more
trouble from
> that module down the road.

Has there been any trouble until now?  Why "fix" something
that wasn't
really broke?

The original bug report (http://www.python.org/sf/810843)
was really
only asking for clarification.  It ends with:

    Nonetheless, I was shocked to see what I thought was a
    straightforward use of ConfigParser throw off errors.

Imagine developers' shock now that we can't do what we want
at all!

Docutils is not the only project using ConfigParser to store
non-strings.  I wouldn't be surprised to see other code
breaking,
which we probably wouldn't find out about until after 2.4-final.

> Sure, the module could be made happy by reverting the
patch you
> cite, but happy-by-accident is a very fragile state to be in.

So let's remove the accident, and make the happiness official!

>> The comment for bug 810843 says "This is documented
behavior", but
>> I couldn't find any such documentation pre-dating this
change.
>
> This may have been a bug in my memory.

Now that the memory bug is fixed, how about reconsidering the
resultant decision?

I'll write a doc patch ASAP.

-- 
David Goodger <http://python.net/~goodger>