Steven D'Aprano <steve+pyt...@pearwood.info> added the comment: Patrick Westerhoff wrote: > Patrick Westerhoff <patrickwesterh...@gmail.com> added the comment: > > I have to agree with Georg on that. I think it would make more sense to > introduce some internal flag/variable that keeps track of if the cause was > explicitely set. So if cause was set (i.e. `from X` syntax is used), then > always display it in favor of the context – except that a None-cause causes > nothing to display. > > Regardless of that I’m actually not sure if just changing the way the cause > is displayed is a correct way to handle the context. If I explicitely raise > an exception in an except-handler, I usually don’t expect that new > exception to get the previous exception attached to.
I'm inclined to agree. I'm not convinced that "raise MyError from None" should leave any trace of the old exception at all. Suppose you have a couple of functions like this: def spam(x): # LBYL if hasattr(x, "__len__"): y = len(x)+1 else: raise MyError("x has no length") do_stuff_with(y) def ham(x): # EAFP try: y = len(x)+1 except TypeError: raise MyError("x has no length") from None do_stuff_with(y) It is entirely an irrelevant implementation detail whether you happen to write spam or ham. The exception that the caller gets should, in my opinion, be the same. I can't see any benefit to exposing the TypeError, even if the caller has to overtly go looking for it in order to see it. But having said that, if others have a specific scenario in mind where they would need to distinguish between spam and ham, I'm happy for the context to be set. But I am curious to learn what the scenario is. Is it just a matter of "just in case"? ---------- _______________________________________ 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