This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.araujo
Recipients BreamoreBoy, eric.araujo, jkaufman, lukasz.langa, michael.foord, ysj.ray
Date 2010-07-28.15:00:18
SpamBayes Score 0.00041797705
Marked as misclassified No
Message-id <1280329220.6.0.857517809653.issue5412@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-07-28 15:00:20eric.araujosetrecipients: + eric.araujo, michael.foord, jkaufman, ysj.ray, BreamoreBoy, lukasz.langa
2010-07-28 15:00:20eric.araujosetmessageid: <1280329220.6.0.857517809653.issue5412@psf.upfronthosting.co.za>
2010-07-28 15:00:18eric.araujolinkissue5412 messages
2010-07-28 15:00:18eric.araujocreate