In the Django thread, I suggested that an implicit "raise from" should be the behavior whenever an exception is raised directly in exception-handling code (that is, within an except: or finally: clause). Ram claimed there were problems with that, but gave no details; I would be happy to know what these problems are.
The main problem I see with "raise from None" is that it removes the inner part of the traceback. It expresses the idea that everything that happened in lower levels is not really interesting -- you should have all the information for handling or debugging the problem by considering the flow from here up. I think in most cases where you'd want to change the type and/or value of an excpetion, this is unrealistic.
With respect to Ram's current suggestion, I think that for it to really make a difference, the "raise as" should not be thought of as a shorthand/variant of "raise ... from", but rather as a variant of bare raise; that is, it should not create a chained exception, but an effect of re-raising while changing the exception value (and potentially type). This, I think, would address Ethan's claim that "this should really be raise from None", without the cons described earlier; it is a better expression of the idea "I just want to change the exception being raised".
To summarize, I am suggesting that
except ExceptionType: raise as OtherException(...)
Have, more-or-less, the semantics of Python 2's:
except ExceptionType: traceback = sys.exc_info() raise OtherException, OtherException(...), traceback
Thanks for your consideration,