Re: [Python-Dev] [Python-checkins] cpython: Issue #11049: adding some tests to test.support
Hi,
changeset: 71465:be558ad15789 user: Eli Bendersky <eliben@gmail.com> summary: Issue #11049: adding some tests to test.support Based on original patch by Giampaolo Rodola with contributions from R. David Murray
files: Lib/test/support.py | 21 +- Lib/test/test_support.py | 178 +++++++++++++++++++++++++++ 2 files changed, 189 insertions(+), 10 deletions(-)
diff --git a/Lib/test/support.py b/Lib/test/support.py --- a/Lib/test/support.py +++ b/Lib/test/support.py @@ -170,7 +170,7 @@ attribute = getattr(obj, name) except AttributeError: raise unittest.SkipTest("module %s has no attribute %s" % ( - obj.__name__, name)) + repr(obj), name))
I would use %r instead of %s for both fields here. Non-ASCII characters and unseen whitespace are at least two reasons to overuse %r in debug/error messages instead of %s. Regards
On Tue, 26 Jul 2011 15:20:55 +0200 Éric Araujo <merwok@netwok.org> wrote:
diff --git a/Lib/test/support.py b/Lib/test/support.py --- a/Lib/test/support.py +++ b/Lib/test/support.py @@ -170,7 +170,7 @@ attribute = getattr(obj, name) except AttributeError: raise unittest.SkipTest("module %s has no attribute %s" % ( - obj.__name__, name)) + repr(obj), name))
I would use %r instead of %s for both fields here. Non-ASCII characters and unseen whitespace are at least two reasons to overuse %r in debug/error messages instead of %s.
Actually, you want %a for non-ASCII messages to be escaped. (however, there's hardly any reason to worry about it when it comes to stdlib module names) Regards Antoine.
Le 26/07/2011 15:30, Antoine Pitrou a écrit :
Actually, you want %a for non-ASCII messages to be escaped.
Thanks for the reminder, I should use more %a instead of %r. In the packaging code however, we can’t, given that we want to backport.
(however, there's hardly any reason to worry about it when it comes to stdlib module names)
I lacked context to see that. If the code in question only ever handles stdlib modules, then okay. Cheers
On Wed, Jul 27, 2011 at 12:10 AM, Éric Araujo <merwok@netwok.org> wrote:
Le 26/07/2011 15:30, Antoine Pitrou a écrit :
Actually, you want %a for non-ASCII messages to be escaped.
Thanks for the reminder, I should use more %a instead of %r. In the packaging code however, we can’t, given that we want to backport.
(however, there's hardly any reason to worry about it when it comes to stdlib module names)
I lacked context to see that. If the code in question only ever handles stdlib modules, then okay.
The other reason to use %r is to get the enclosing quotes in the displayed message. That reason applies even in cases like this where the escaping aspect isn't a concern. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Tue, Jul 26, 2011 at 17:41, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Wed, Jul 27, 2011 at 12:10 AM, Éric Araujo <merwok@netwok.org> wrote:
Le 26/07/2011 15:30, Antoine Pitrou a écrit :
Actually, you want %a for non-ASCII messages to be escaped.
Thanks for the reminder, I should use more %a instead of %r. In the packaging code however, we can’t, given that we want to backport.
(however, there's hardly any reason to worry about it when it comes to stdlib module names)
I lacked context to see that. If the code in question only ever handles stdlib modules, then okay.
The other reason to use %r is to get the enclosing quotes in the displayed message. That reason applies even in cases like this where the escaping aspect isn't a concern.
And then you make it {!r} so you can use str.format and you complete the tweak of the string formatting! =) Seriously, though, it wouldn't hurt to update it to use str.format().
On 27/07/2011 03:04, Brett Cannon wrote:
On Tue, Jul 26, 2011 at 17:41, Nick Coghlan <ncoghlan@gmail.com <mailto:ncoghlan@gmail.com>> wrote:
On Wed, Jul 27, 2011 at 12:10 AM, Éric Araujo <merwok@netwok.org <mailto:merwok@netwok.org>> wrote: > Le 26/07/2011 15:30, Antoine Pitrou a écrit : >> Actually, you want %a for non-ASCII messages to be escaped. > > Thanks for the reminder, I should use more %a instead of %r. In the > packaging code however, we can't, given that we want to backport. > >> (however, there's hardly any reason to worry about it when it comes to >> stdlib module names) > > I lacked context to see that. If the code in question only ever handles > stdlib modules, then okay.
The other reason to use %r is to get the enclosing quotes in the displayed message. That reason applies even in cases like this where the escaping aspect isn't a concern.
And then you make it {!r} so you can use str.format and you complete the tweak of the string formatting! =) Seriously, though, it wouldn't hurt to update it to use str.format().
Well, except that {!r} is twice as verbose as %r.... Michael
_______________________________________________ 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/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
I would use %r instead of %s for both fields here. Non-ASCII characters and unseen whitespace are at least two reasons to overuse %r in debug/error messages instead of %s.
Actually, you want %a for non-ASCII messages to be escaped. (however, there's hardly any reason to worry about it when it comes to stdlib module names)
I wasn't aware of '%a' at all? It doesn't appear to be documented, and Python 2.6 doesn't support it: ValueError: unsupported format character 'a' (0x61) at index 1 If it's new, it should at least be documented in library/stdtypes with the other formatting operations. Eli
On Wed, 27 Jul 2011 16:31:54 +0300 Eli Bendersky <eliben@gmail.com> wrote:
I wasn't aware of '%a' at all? It doesn't appear to be documented, and Python 2.6 doesn't support it:
ValueError: unsupported format character 'a' (0x61) at index 1
If it's new, it should at least be documented in library/stdtypes with the other formatting operations.
It's new in 3.x and maps to the ascii() builtin:
ascii('hé') "'h\\xe9'" '%a' % 'hé' "'h\\xe9'"
The docstring for ascii(): ascii(object) -> string As repr(), return a string containing a printable representation of an object, but escape the non-ASCII characters in the string returned by repr() using \x, \u or \U escapes. This generates a string similar to that returned by repr() in Python 2. Regards Antoine.
On Wed, Jul 27, 2011 at 16:44, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 27 Jul 2011 16:31:54 +0300 Eli Bendersky <eliben@gmail.com> wrote:
I wasn't aware of '%a' at all? It doesn't appear to be documented, and Python 2.6 doesn't support it:
ValueError: unsupported format character 'a' (0x61) at index 1
If it's new, it should at least be documented in library/stdtypes with
the
other formatting operations.
It's new in 3.x and maps to the ascii() builtin:
ascii('hé') "'h\\xe9'" '%a' % 'hé' "'h\\xe9'"
The docstring for ascii():
ascii(object) -> string
As repr(), return a string containing a printable representation of an object, but escape the non-ASCII characters in the string returned by repr() using \x, \u or \U escapes. This generates a string similar to that returned by repr() in Python 2.
Thanks. I also saw this documented in the {!a} formatting documentation. Was it left out of the library/stdtypes doc on purpose (to encourage the new str.format), or is this an omission? Eli
Le mercredi 27 juillet 2011 à 16:54 +0300, Eli Bendersky a écrit :
Thanks. I also saw this documented in the {!a} formatting documentation.
Was it left out of the library/stdtypes doc on purpose (to encourage the new str.format), or is this an omission?
Certainly an omission. Regards Antoine.
Thanks. I also saw this documented in the {!a} formatting
documentation.
Was it left out of the library/stdtypes doc on purpose (to encourage the new str.format), or is this an omission?
Certainly an omission.
Alright, I created issue 12644 as a reminder to add this. Eli
participants (6)
-
Antoine Pitrou -
Brett Cannon -
Eli Bendersky -
Michael Foord -
Nick Coghlan -
Éric Araujo