Ethan Furman <et...@stoneleaf.us> added the comment: > Besides, if you are writing library code (as opposed to application > code), you shouldn't care at all how tracebacks are displayed, should > you?
I care when it lies: During handling of the above exception, another exception occurred: This is a blatant falsehood -- another exception did not occur, a different exception was raised. Now, when another exception does actually occur, I'm all for the nested traceback, but if I'm raising a different one, why is this useful: --> d.address Traceback (most recent call last): File "nested_exceptions.py", line 7, in __getattr__ return self.data[self.names.index(name)] ValueError: tuple.index(x): x not in tuple During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "nested_exceptions.py", line 9, in __getattr__ raise AttributeError("Attribute %s does not exist" % name) AttributeError: Attribute address does not exist ? Furthermore, I use my own library, and have no interest in seeing extra, completely unnecessary, and wrong (verbiage, anyway) traceback info -- not in my own libraries, nor in other's that I may be using. Keep the nesting for when an exception actually occurs, not for when an exception is, under programmer control, being modified/changed. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6210> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com