Éric Araujo <mer...@netwok.org> added the comment: Note that the two versions are not exclusive: We can look for an item if a tuple is given and look for a section if it’s a string. Maybe confusing.
> - we can implement a cohesive mapping protocol that extends to get(), > del, in, etc. For now get() seems somewhat similar to what > dictionaries give you We have the same problem in distutils2 with a class that supports some mapping operations but has an incompatible get method. Luckily we can still break compat there. The winning argument in my opinion is user convenience, not moderate implementation issues. Is is generally useful that config parsers and sections behave like mutable mappings? Then add the methods with the behavior I proposed. Are there compatibility problems and not much incentive? Then do it your way, and add another mechanism for my wished use. It looks like we have to go for the latter. > - manipulation on the internal structures is much simpler when we > have a single key like that. Having config['name'] return the section > would make us create another proxy object just to support mutating > keys in the section. Yeah, dict/DictMixin subclasses that implement checking and conversion wouldn’t be hard to write, but maybe it’s not worth it and we just need a method to convert the config parser to a dict (already easy with sections: dict(cp.items(section)) So if every other config parser supports cp['section', 'key'], I’m +1. I can get a real dict for a section, and I’ll open another report to request methods update and asdict methods for RawConfigParser. ---------- title: extend configparser to support [] syntax -> extend configparser to support mapping access(__*item__) _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5412> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
