Getting *rid* of the name ConfigParser would be annoying and cause *gratuitous* code breakage.

If we are going to keep the name but get rid of the "unsafe" version then we can only replace it with what is now SafeConfigParser - as it is almost entirely compatible with it. (Modulo the bug fixing "behavioural change".)

So the real choices are:

* leave ConfigParser as it is
* deprecate it but not remove it (so as not to needlessly break code)
* deprecate now and replace with SafeConfigParser later

Only the last of these is a positive step forwards... :-)

(Strongly -1 on introducing *yet another name* to refer to these classes by.)