Re: [Python-Dev] Repo frozen for 3.2
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 ___ 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
Re: [Python-Dev] Repo frozen for 3.2
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.uk -- 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. ___ 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
Re: [Python-Dev] Repo frozen for 3.2
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. "A storm broke loose in my mind." --Albert Einstein ___ 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
Re: [Python-Dev] Repo frozen for 3.2
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 ___ 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
Re: [Python-Dev] Repo frozen for 3.2
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. "A storm broke loose in my mind." --Albert Einstein ___ 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
Re: [Python-Dev] Repo frozen for 3.2
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. ___ 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
Re: [Python-Dev] Repo frozen for 3.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2010 01:06 PM, s...@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 tsea...@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- ___ 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
Re: [Python-Dev] Repo frozen for 3.2
Vinay> ... the deprecation of ConfigParser for 3.2 What's the rush? It's been deprecated, not removed. Skip ___ 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
Re: [Python-Dev] Repo frozen for 3.2
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. "A storm broke loose in my mind." --Albert Einstein ___ 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
Re: [Python-Dev] Repo frozen for 3.2
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/ ___ 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
[Python-Dev] Repo frozen for 3.2
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? Regards, Vinay Sajip ___ 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