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

[Tim Peters]

[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 "<stdin>", 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.