> 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.