Ah, yes, ConfigParser, the red-headed stepchild of Python serialization. It seems ConfigParser has been around for a /very/ long time... and it shows. In particular, its interface is pretty clunky when viewed with a modern Python programmer's eye. I propose hacking up ConfigParser so it has a more Pythonic interface--specifically, so it acts more-or-less like a two-level nested dict. I'll call the rewritten module "configdict" for now. Here's the full list of what I have in mind: * a configdict object behaves like a dict, but can only contain configdict.section objects * a configdict.section object behaves like a dict, but can only contain strings * obviously, configdict and configdict.section would be new-style classes * write the initial implementation as a wrapper around RawConfigParser * "defaults" argument to constructor -> configdict.update() or configdict[section].update() * sections() -> configdict.iternames() * add_section(s) -> configdict[s] = section * has_section(s) -> s in configdict * readfp(fp) -> configdict.read(fp) * add a new function parse(s) which parses s as if it were a file (probably just wraps in stringio and calls read()) * get(section, option) -> configdict[section][option] or configdict[section].get(option) * items(section) -> configdict[section].iteritems() * write(fp) -> unchanged * remove_option(section, option) -> del configdict[section][option] * remove_section(section) -> del configdict[section] * drop read(filenames), getint(), getboolean() * not sure how I feel about optionxform(), could keep it, could drop it * drop the spooky "magic interpolation feature" entirely (explicit, not implicit) Worth pursuing? Cheers, /larry/