I think this may be dangerous, especially if you try to debug this at a
later time. Better to just limit the printing itself with the negative
tracebacklimit parameter.
This brings up another issue (yes, we keep generating new/rehash old issues
:-). I would rather see that the exceptions themselves contain some more
information, instead of having to pull it out of the sys module. Although
Guido doesn't find it all that useful, I would find it more intuitive if the
exception itself contains the information about the type, value, traceback
etc. Then it could also have the methods reraise(), retry() and ignore() (or
something similar) to raise the exception with the original traceback but
without being caught by the same handler, retry the block that raised the
exception, or ignore it altogether and continue executing from the point you
left of. This doesn't make the borderline case of wanting to skip the
outermost two frames any easier, unless you can modify the traceback. As
stated above, I'm not sure whether that would be a good idea.
Of course this may entail having to introduce a new object, the exception
object, and instead of using strings as the error object, you would actually
use the exception object. E.g.:
index_error = exception('substring not found in string.index')
def index(s, sub, *args):
...
index_error.raise((s, sub) + args)
The try statement needn't be changed, althoug the type becomes superfluous
(you would need it for backwards compatibility).
-Jaap-