On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger firstname.lastname@example.org wrote:
We really ought to stop with the SafeFoo naming convention. It is only descriptive to the person who wrote the class or function, not to the user who will immediately wonder, "safe from what?"
Safe from bad vampire movies, of course!
I'd not recognize the current Safe* class names as a pattern; there are currently two in the py3k trunk:
configparser.SafeConfigParser -- very much a poor name
xmlrpc.client.SafeTransport -- perhaps should have been SSLTransport or HTTPSTransport
I agree the "Safe" prefix isn't meaningful. SafeConfigParser might even be my fault.
Michael Foord has lobbied to end up with the "preferred" configparser class to be named (eventually) ConfigParser, with good reason. It's not clear to me that we want to do that for backward compatibility reasons (as I've argued elsewhere). Were it not for that issue, I'd be in favor of using different/better names. (And there's still space for better names, if we can create new names that avoid the b/w compatibility issues.)
-- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein