ConfigParser behavior change
Could I get some feedback re <http://www.python.org/sf/997050>? I'd like to resolve this before 2.4a2 if possible. In summary, RawConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I specifically chose RawConfigParser for Docutils internal settings support because it *did* allow non-string values. An earlier bug report (<http://www.python.org/sf/810843>, "Support for non-string data in ConfigParser unclear/buggy") offered 4 options: (1) Cast the option to a string explicitly instead of assuming it is a string (2) Check that the option is a string (3) State in the documentation that the set() method only takes string values (4) State in the documentation that the raw parameter should be used when an option's value might not be of type string Options 2 & 3 were implemented in the "bug fix" (just a type check). I think that the behavior should not have been changed, rather that the documentation needed updating (i.e., choose option 4 instead). I volunteer to undo the change and update the documentation ASAP. The comment for bug 810843 says "This is documented behavior", but I couldn't find any such documentation pre-dating this change. Thanks! -- David Goodger <http://python.net/~goodger>
On Monday 02 August 2004 10:13 am, David Goodger wrote:
Could I get some feedback re <http://www.python.org/sf/997050>? I'd like to resolve this before 2.4a2 if possible.
David has (properly) been asking me to look into this, and i've managed not to have enough time. Sorry, David!
RawConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I specifically chose RawConfigParser for Docutils internal settings support because it *did* allow non-string values.
An earlier bug report (<http://www.python.org/sf/810843>, "Support for non-string data in ConfigParser unclear/buggy") offered 4 options:
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. I think allowing them is just asking for still more trouble from that module down the road. 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.
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. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
[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> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBDrJ4rqIPjB1FxosRAukuAKC7f+kVLdldTR9KYp37NwtSgLusGgCgoKk6 DIRhoTwMbgq8J0tdLA8HIQA= =1m0G -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBDrNprqIPjB1FxosRAhHcAKC6DirbHmFxgJzg7/3H3uuCQVArKwCgtOvj 9wfN1aC46bB7aauKkcem+tQ= =jRi8 -----END PGP SIGNATURE-----
participants (2)
-
David Goodger -
Fred L. Drake, Jr.