The purpose of the from clause in general is to change the exception *type* (for example, from KeyError -> AttributeError or vice-versa), or to add additional information without losing access to any previous information (like the original traceback). This is covered in PEP 3134.

In some cases, the appropriate way to convey the information is to copy relevant details to the new exception, leave the context set, and suppress display of that context by default. In other cases, the developer may want to display the chained exception explicitly, because it *isn't* part of the current exception handling context (e.g. this is quite likely in an event loop scheduler that passes exception information between events - the __cause__ chain would track the *event stack* rather than the Python call stack).

Thus, in the recommended use for the "raise X from Y" syntax, you're always setting __cause__ on a *new* exception, so you know you're not overwriting a preexisting __cause__ and thus there's no risk of losing information that might be relevant for debugging the failure.

When you use "raise X from Y" directly on a *pre-existing* exception (however you managed to get hold of it), there's a chance that __cause__ is already set. If you blindly overwrite it, then you've deleted part of the exception chain that PEP 3134 is designed to preserve.

This is also why Guido and I were so adamant that just setting __context__ to None was not an acceptable solution for PEP 409 - the whole point of PEP 3144 is to make it difficult to accidentally lose the full details of the traceback even if some of the exception handlers in the stack are written by developers that don't have much experience in debugging other people's code.