From: Felix W. <Fel...@gm...> - 2006-01-22 14:23:45
|
David Goodger wrote: > Here's a possible solution: extend ConfigParser to recognize the "+=" > syntax: > > added_stylesheet_paths = website_default.css > added_stylesheet_paths += fancy.css Then you could do without added_stylesheet_paths and just write: stylesheet_path += website_default.css stylesheet_path += fancy.css This would be exactly the same, except for the syntax. We'd just need to live with the fact that we add a value to a setting that reads singular ("path", not "paths"). But that would be OK with me. Regarding the "one value per indented line syntax": Well, it's possible. I still don't really like it, but I can understand the reasoning behind it. OTOH the += syntax is possible just as well and I think it looks a lot nicer. > This is explicit. The setting's initial type could be a string, and > auto-convert to a list when "+=" is seen; That seems reasonable, as it would also maintain backwards compatibility to the existing API. > that way, we don't have to inform ConfigParser beforehand the types of > settings. But at least we need a list of settings which *can* become lists. I.e. for every existing setting except stylesheet[_path] I still want to be able to assume that it's *always* a string (or int, or whatever) unless called via the API of course. So rfc_base_url = http://foo rfc_base_url += http://bar must cause an error at the config parser level. The reST parser shouldn't have to check if rfc_base_url has become a list. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |