On Mon, 06 Dec 2010 13:02:41 -0800, Raymond Hettinger email@example.com wrote:
On Dec 6, 2010, at 11:40 AM, Fred Drake wrote:
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.
IIRC, pprint has a safe_repr() and string.Template has safe_substitute() and pydoc has a safe import.
Never new there was so much danger in the standard library :-)
unittest has an (internal) safe_repr, too. I understand all four of these to be "versions of xxx that won't raise". I think that's a reasonable use of the word 'safe', but perhaps there is something better.
SafeConfigParser doesn't follow that pattern, of course, though it is perhaps true that it would raise errors a bit less often... :)
-- R. David Murray www.bitdance.com