> This not only happens when get() after a set(), but with all the use cases
> above. An intervening write()/read() does not change things.
> But I'm not sure it is a bug really. If all % were escaped automatically,
> there is no way to write a templatized value. Maybe SafeConfigParser.set
> should grow an escape argument, controlling whether one wants the value
> escaped or not. For compatibility reasons should default to False, for
> usability reasons should default to True.
The exception is only raised when get is called, the "raw" paremeter
for get(...) is set to False (default) and the string value for that
parameter contains a single "%". None of the cases I stated above call
get() after calling set(). So, the exception will never be raised
because of something the user set. It will be raised if the input file
happens to have a single "%" character in one of the parameter values,
but that content could have been user generated, and it is not
reasonable to assume that fixing the set() method would have prevented
it.
Adding an escape parameter to set will not be used properly. Its
purpose would be to escape lone "%" characters, but if users are
wanting to use the substitution they would always keep escaping off.
It wouldn't allow them catch situations like this:
cp.set("sect","param","this is my value %(key)s and here is a lone %
and here is another %(sub)s", escape=False)
The solution I would propose is to raise an exception on set() if the
value contains a single "%" not followed by a key name enclosed in
parens followed by "s". That puts the burden of escaping on the user,
before passing it to set.
--
http://mail.python.org/mailman/listinfo/python-list
