testtools should be able to cope with non-ascii tracebacks
Bug #501166 reported by
Martin Packman
This bug affects 6 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
testtools |
Fix Released
|
Critical
|
Martin Packman |
Bug Description
The testtools.
value = self._result.
super(
Here value is a str object, trying to encode it uses the default encoding (generally ascii) to decode it to unicode before encoding as UTF-8 and throws if the str is not 7-bit clean.
This code is fixable, however I think the mime-types model for test metadata is overly complicated, fragile, and generally a bad idea.
Related branches
lp:~gz/testtools/unicode_tracebacks_501166
- Robert Collins: Needs Fixing
- testtools developers: Pending (preliminary) requested
-
Diff: 1056 lines (+793/-37)12 files modifiedNEWS (+4/-0)
testtools/__init__.py (+1/-1)
testtools/compat.py (+191/-15)
testtools/content.py (+3/-3)
testtools/run.py (+2/-2)
testtools/testcase.py (+1/-1)
testtools/testresult/real.py (+33/-12)
testtools/tests/__init__.py (+2/-0)
testtools/tests/test_compat.py (+241/-0)
testtools/tests/test_content.py (+1/-1)
testtools/tests/test_testresult.py (+301/-2)
testtools/testsuite.py (+13/-0)
Changed in testtools: | |
status: | Triaged → In Progress |
Changed in testtools: | |
milestone: | none → next |
status: | In Progress → Fix Released |
To post a comment you must log in.
On Mon, 2009-12-28 at 23:35 +0000, Martin [gz] wrote: content. TracebackConten t class is not robust against _exc_info_ to_string( err, test) Content, self)._ _init__ (content_ type, [value. encode( "utf8") ])
> Public bug reported:
>
> The testtools.
> tracebacks where either the exception value, a script filename, or a
> script line contains non-ascii text. The particular problem is with the
> lines:
>
> value = self._result.
> super(Traceback
> lambda:
>
> Here value is a str object, trying to encode it uses the default
> encoding (generally ascii) to decode it to unicode before encoding as
> UTF-8 and throws if the str is not 7-bit clean.
So, for value to be a 'str' and not 7-bit clean:
- you need an ascii file system encoding
- you need non-ascii paths in the file system
- and ascii symbol names throughout
or
- test data that raises an AssertionError which has a str that is not
ascii.
Are there other causes for a non-ascii 'str' value there?
Anyhow, clearly we should fix this
status triaged
importance critical
I suggest that fixing it 'the right way' will be tricky for Python2.x,
because up till to Python 2.7 str(Exception) blows up badly with unicode
args in a few ways. So we probably need to change the stringification
logic to handle this case and return a 'unicode' value not a 'str'
value. However I think we currently use that largely as-is from Python
core. I can't look at this right now, but I think its very important to
fix.
> This code is fixable, however I think the mime-types model for test
> metadata is overly complicated, fragile, and generally a bad idea.
Well, its been hugely successful for me already in the few places I've
deployed it, so with respect: I disagree. For instance, its already
solved a major bug with subunit + bzr selftest which shows up readily in
selftest --parallel. The code is simple, nearly trivial, and the
specifications (for e.g. MIME) are readily available allowing rampant
reuse by other tools.
Backtraces and test data in /general/ are for showing to humans but also
need to be machine processable (e.g. to look for common patterns or
encode and transmit to remote machines) and MIME has had many many
successes at bridging these two needs including both HTTP and SMTP.
-Rob