[Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS (original) (raw)

Tim Peters tim.peters at gmail.com
Thu Apr 13 04:02:10 CEST 2006


[Tim]

... Fine by me if we change the failing tests on the trunk to pass (noting that should have been done before checking in).

[Phillip]

It's not fine by me if the reason for the failure is that doctests trapping specific exceptions no longer work with the patch.> If that's the case, the patch should be reverted entirely, absent any compelling reasoning for breaking everyone else's doctests in 2.5.

I agree with the patch author's position that "it's a bug" that the traceback module's functions' output doesn't match the interpreter's traceback output. That certainly wasn't intended; it's most likely left over from the days when only strings could be exceptions, and nobody noticed that the old traceback-module code "didn't work exactly right" anymore when the notion of exceptions was generalized.

WRT doctests, it's a mixed bag. Yes, some tests will fail. doctests are always vulnerable to changes "like this". OTOH, the change also simplifies writing new doctests. I remember being baffled at doing things like:

import decimal 1 / decimal.Decimal(0) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\decimal.py", line 1314, in rdiv return other.div(self, context=context) File "C:\Python24\lib\decimal.py", line 1140, in div return self._divide(other, context=context) File "C:\Python24\lib\decimal.py", line 1222, in _divide return context._raise_error(DivisionByZero, 'x / 0', sign) File "C:\Python24\lib\decimal.py", line 2267, in _raise_error raise error, explanation decimal.DivisionByZero: x / 0

in an interactive shell, pasting it into a doctest, and then seeing the doctest fail because the exception name "somehow" magically changed to just "DivisionByZero". I got used to that before I found time to understand it, though. Future generations wouldn't suffer this cognitive dissonance.

A less-desirable (IMO) alternative is to change the Python core to display bare (non-dotted) exception names when it produces a traceback. The fundamental bug here is that the core and the traceback module produce different tracebacks given the same exception info, and changing either could repair that.



More information about the Python-Dev mailing list