Patrick Westerhoff wrote:
> Patrick Westerhoff <PatrickWesterhoff@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"?