On Fri, Apr 25, 2014 at 12:46:42PM -0400, Fred Drake wrote:
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin firstname.lastname@example.org wrote:
While it seems ConfigParser doesn't do any escaping as all, I'm thinking it should at least raise some exception when such a value is trying to be set.
I'd expect writing something and then reading it back via the same configparser to always result in the same data, as long as writing worked without error.
Thoughts? Should I submit a bug report?
I believe you should, if only to provide a place to record why no change gets made.
Had ConfigParser been more careful from the beginning, that would have been really good.
At this point, it would be a backward-incompatible change, so it's unlikely such a change could be allowed to affect existing code.
It seems to me that the current behaviour is a bug and should be fixed. I think the relevant part of the docs is the part following the "comment_prefixes" and "inline_comment_prefixes" section:
Please note that config parsers don’t support escaping of comment prefixes so using inline_comment_prefixes may prevent users from specifying option values with characters used as comment prefixes. When in doubt, avoid setting inline_comment_prefixes. In any circumstances, the only way of storing comment prefix characters at the beginning of a line in multiline values is to interpolate the prefix, for example: ...
This is seriously underspecified, which is a bug in itself: option values don't support including inline_comment_prefixes, but do option keys support them? How about keys beginning with comment_prefixes? The specification doesn't say, but nor does it say that it's undefined behaviour.
I think that a line beginning with "#spam" is ambiguous, it isn't clear if it is intended as a comment "spam" or a key starting with #, so by the Zen, configparser should refuse to guess.