More globals of course defeat the purpose (one of the reasons for putting the traceback in the exception is to get rid of sys.exc_traceback).
I think the idea was that this would be a C-level global, not a Python one (i.e. part of the existing group of C variables representing the current exception state).
Possibly, except those aren't globals either (they're members of the per-thread state record).
I also think that doing this automatically whenever PyErr_Set*() is called would cause a lot of spurious tracebacks. (Unless the idea is to skip the chaining if the original exception has an empty traceback
I don't understand that. What is a "spurious" traceback? And how are you going to get one if the current traceback is empty?
I was imagining that the default mechanism for printing tracebacks would always try to follow the chain of tracebacks, and report not just the traceback, but also the exception that was replaced. There's a lot of C code out there that catches e.g. AttributeError and replaces it with a more specific error (e.g. BifurcationError("can't bifurcate the sploorg") replacing AttributeError("__bifurcate__"). I think this would cause end user confusion.
I worry about backwards compatibility.
What would this break? Code which doesn't know about chained exceptions can just ignore the new attribute and get exactly the information they used to get from the exception and its traceback, as far as I can see.
I didn't mean code breakage, but the above change in output. --Guido van Rossum (home page: http://www.python.org/~guido/)