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 lukasz.langa
Recipients brett.cannon, eric.araujo, fdrake, georg.brandl, lukasz.langa, michael.foord, r.david.murray, rhettinger, till
Date 2010-08-03.11:21:13
SpamBayes Score 4.4565425e-08
Marked as misclassified No
Message-id <>
In-reply-to <>
> 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.
Date User Action Args
2010-08-03 11:21:16lukasz.langasetrecipients: + lukasz.langa, fdrake, brett.cannon, georg.brandl, rhettinger, eric.araujo, r.david.murray, michael.foord, till
2010-08-03 11:21:14lukasz.langalinkissue6517 messages
2010-08-03 11:21:13lukasz.langacreate