SafeConfigParser can set unsafe values

Gabriel Genellina gagsl-py2 at yahoo.com.ar
Tue Jul 10 22:40:02 EDT 2007


En Tue, 10 Jul 2007 20:53:51 -0300, Matimus <mccredie at gmail.com> escribió:

>> Should SafeConfigParser.set() be escaping automatically?
>
> It seems like that would be a nice feature. However, may I offer up
> that if you are setting an option and then later on getting that value
> back in the same program, you probably should have used some other
> storage mechanism in the first place. That is, you shouldn't store
> values needed during the runtime of your program in a ConfigParser
> instance.
>
> As far as I can tell, these are the valid use cases for ConfigParser:
>
> 1. Use ConfigParser to read values from an config file
>     - This implies .read() followed by .get()s
> 2. Use ConfigParser to create and write a config file
>     - This implies .set()s followed by .write()
> 3. Use ConfigParser to read, modify and write a config file.
>     - This implies .read() followed by .get()s followed by .set()s
> followed by .write()
>
> None of the above use cases involve calling .get() after a .set().
> Perhaps I am missing a use case though.
>
> While I think you have technically pointed out a potential bug, I'm
> not sure why it matters. Such a bug only comes about for (IMHO) flawed
> use cases.

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.

-- 
Gabriel Genellina




More information about the Python-list mailing list