UnicodeDecodeError crack in doctest
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Unassigned | ||
zope.testing |
Fix Released
|
High
|
Christian Theune |
Bug Description
Putting this in a doctest will result in an UnicodeDecodeError when running it:
Unicode crack:
>>> print u'abc'
abc
>>> print u'\xe9'
é
Traceback (most recent call last):
File "/usr/lib/
testMethod()
File "/home/
failures, tries = runner.run(
File "/home/
return self.__run(test, compileflags, out)
File "/home/
got = self._fakeout.
File "/home/
result = StringIO.
File "/usr/lib/
self.buf += ''.join(
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)
This is crack because if you remove one or the either test. The test will run just fine.
Also, if you replace the ur'' with a regular r'', it will also run fine. You can place the ur'' print below the other one and you'll also get the error.
What is frustating is that you don't have any idea where this error comes from since it aborts the whole output printing.
What is the moral here, is that once there are 8bit characters printed on the doctest stdout, it sets a UnicodeDecodeError time bomb that will trigger as soon as any unicode string is printed. And trust me, you can have a hard time knowing which print statement generated 8bits non-unicode string.
Changed in launchpad: | |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in launchpad: | |
milestone: | 1.1.10 → 1.1.11 |
Changed in launchpad: | |
milestone: | 1.1.11 → none |
Changed in launchpad-foundations: | |
assignee: | flacoste → nobody |
tags: |
added: build-infrastructure removed: infrastructure test-system |
tags: | added: tech-debt |
tags: | added: bugday20100424 |
Changed in zope.testing: | |
status: | Incomplete → Fix Released |
Changed in launchpad-foundations: | |
status: | Fix Committed → Fix Released |
This is a Zope or Python bug, isn't it?