On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> 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
--
Fred L. Drake, Jr. <fdrake at acm.org>
"A storm broke loose in my mind." --Albert Einstein
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4