2010/12/5 Łukasz Langa :

On a related note, if you're sure logging users don't use any interpolation, you can also use SafeConfigParser(interpolation=None) so then all values become raw by default (e.g. people can use Python string formatting directives, % signs etc.). We can discuss this later on  when the time comes for that.

This is the hard part, though. So long as the users decide whether to use the interpolation features, it has to be treated as an API compatibility issue. The interpolation syntax is a feature of the language being parsed more than a code-level feature. It's actually a good thing logging is using the ancient ConfigParser, since the interpolation handling is so broken there's unlikely to be any affected uses of '%' in working configurations.   -Fred -- Fred L. Drake, Jr.    <fdrake at acm.org> "A storm broke loose in my mind."  --Albert Einstein

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2010 01:06 PM, skip@pobox.com wrote:

Vinay> ... the deprecation of ConfigParser for 3.2....

What's the rush? It's been deprecated, not removed.

Having modules in the stdlib ship trigger (not raise) DeprecationWarnings is bad housekeeping / "broken window" stuff: it leads application developers to ignore them. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz749YACgkQ+gerLs4ltQ6WyACcDrHkqRVYl11ctTJ5AswTK51Q evMAni7X2BdCbkyXzX7vLQCNMzoMj1yg =Ui6Y -----END PGP SIGNATURE-----

On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger 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

On Mon, Dec 6, 2010 at 4:02 PM, Raymond Hettinger wrote:

IIRC, pprint has a safe_repr() and string.Template has safe_substitute() and pydoc has a safe import.

pprint.saferepr Ok, this one's my fault as well. Probably should just be named repr. string.Template.safe_substitute Agree on this as well. pydoc.safeimport Not documented, so I don't really care what it's called.

Never new there was so much danger in the standard library :-)

You should have known this, Raymond! It's software.   -Fred -- Fred L. Drake, Jr.    <fdrake at acm.org> "A storm broke loose in my mind."  --Albert Einstein

On Mon, 06 Dec 2010 13:02:41 -0800, Raymond Hettinger wrote:

On Dec 6, 2010, at 11:40 AM, Fred Drake wrote:

...

On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger 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