Reposted for reference what originally only went to Vinay. Wiadomość napisana przez Vinay Sajip w dniu 2010-12-05, o godz. 12:36:

I've just been notified via being added to the nosy list of

http://bugs.python.org/issue10627

about the deprecation of ConfigParser for 3.2. I presume I was added to this list because logging.config uses ConfigParser, but logging.config doesn't use any interpolation features so I could easily change all usages to SafeConfigParser; should I do it now (before the 3.2 beta is cut) or hold off for now?

Hold off, just like distutils2 etc. :) I finished the deprecation patch too late and so #10627 was created literally hours (if not minutes) before the freeze. Sorry for that. 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. -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/

Vinay> ... the deprecation of ConfigParser for 3.2.... What's the rush? It's been deprecated, not removed. Skip

On Dec 5, 2010, at 3:36 AM, Vinay Sajip wrote:

I've just been notified via being added to the nosy list of

http://bugs.python.org/issue10627

about the deprecation of ConfigParser for 3.2. I presume I was added to this list because logging.config uses ConfigParser, but logging.config doesn't use any interpolation features so I could easily change all usages to SafeConfigParser; should I do it now (before the 3.2 beta is cut) or hold off for now?

+1 for doing the update now. There's no advantage in continuing to use the old ConfigParser. With respect to beta feature freeze, that should really just mean not adding prominent new major features. We're still free to implement bug fixes, make the language more consistent, propagate the existing changes (such as SafeConfigParser), tweak any of the new APIs, and reconsider or rework some of the new features (such as transform/untransform). Raymond P.S. 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 can mean "sanitized", "won't raise an error", "has a default value", "doesn't use eval/exec", "is secure", "has a known encoding", etc.

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 :-) Raymond

On 06/12/2010 21:02, 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 :-)

What would you name those functions instead? (SafeConfigParser is a naff name and only needed because ConfigParser is broken.) Michael

Raymond _______________________________________________ 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/fuzzyman%40voidspace.org.u...

-- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.