Łukasz Langa <luk...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue6517> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
