Matimus wrote:
>> I agree, but that was a trivial example to demonstrate the problem.
>> Writing the file out to disk writes it exactly as set(), causing a get()
>> to fail just the same later.
>
> No... The above statement is not true.
Yes, it is. Whatever you set gets written out directly. Your example
proves this:
> cp.set("sect","opt","hello%world")
> cp.write(sys.stdout)
> [/code]
>
> Produces this output:
> [sect]
> opt = hello%world
Then when you get() this value later, it fails.
> The write method never calls get. However, when you read the file that
> was output by the above code using .get(...) will raise an error. You
> can avoid that error by setting the optional 'raw' parameter to True.
But then you have disabled substitution, which is not the same thing! I
don't necessarily want to disable substitution, I just want transparent
handling of lone %s.
Since SafeConfigParser.get() is fussy about the format of interpolation
instructions, SafeConfigParser.set() can safely know when you're not
trying to use them and escape lone percents.
To summarise: set() should not set something which get() will ALWAYS
fail on!
Hamish
--
http://mail.python.org/mailman/listinfo/python-list
