Consider the following traceback:

Traceback (most recent call last):
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in __getattr__
    return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
    self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in replace_header
    print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in __getattr__
    self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'


The first traceback, which is supposed to be the "primary" error, gives
no indication of where the problem occured.  It starts with a fairly
deeply nested call.  The second traceback does show the line where the
error occured in the except statement, but you have to read the lines
above it to find the line that actually triggered the original
traceback.

I think it would be much better if either the full traceback were
given for the first traceback, or for both of them.  I realize
that the short traceback for the first traceback is how things
have "traditionally" worked when exceptions are caught, but as
evidenced by issue 1553375 this is often not the desired behavior
even before the existence of chained exceptions.