[issue6517] Emphasising in the docs configparser.SafeConfigParser over ConfigParser
Łukasz Langa
report at bugs.python.org
Tue Aug 3 13:21:16 CEST 2010
Łukasz Langa <lukasz at langa.pl> added the comment:
> If ConfigParser is not documented first, the name “SafeConfigParser” becomes strange—safe compared to what?
The first sentence is "Derived class of ConfigParser that implements a sane variant of the magical interpolation feature." I think it's enough for an explanation.
If this were an encyclopedia, you would be right. But this is more like a Google search results page. Most people will take the first thing that looks like a solution they need.
> These names have an historical motivation and could become clearer if renamed
That is the point.
> but I don’t know if python-dev will agree with this deprecation.
That would be a shame, essentially it should happen in 3.0 IMO. But it's never too late I think.
Think of the children! One day you will read this comment and think: whoa, this was even BEFORE 3.2! Yeah, ancient history.
> Renaming a class to an existing name with different behavior can be bad.
Yes but this is going to be a problem for 3.4. Maybe then we'll come up with something more natural.
> FTR, in my head RawConfigParser is the config parser, and SafeConfigParser is another thing that I’ll maybe use one day.
YMMV. FTR, many people I've spoken to treated RawConfigParser as something more low-level and not suitable for consumer use just because of the name AND the presence of a default (=name like the module) ConfigParser class.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6517>
_______________________________________
More information about the Python-bugs-list
mailing list