On Mon, 06 Dec 2010 13:02:41 -0800, Raymond Hettinger <raymond.hettin...@gmail.com> wrote: > On Dec 6, 2010, at 11:40 AM, Fred Drake wrote: > > On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger > > <raymond.hettin...@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. > > 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
