Barry Warsaw wrote: > raise e from ... > > is certainly cute, but not very informative. Triple-dots will be confusing > and difficult to read in documentation and code, and Ellipsis has no logical > connection to the purpose of this PEP. So while I'm +1 on everything else in > the PEP, I'm -1 on this particular decision. > > One of the alternatives states: > > Create a special exception class, __NoException__. > > Rejected as possibly confusing, possibly being mistakenly raised by users, > and not being a truly unique value as None, True, and False are. > > I think this should be revisited. First, `__NoException__` doesn't need to be > an exception class. Ellipsis isn't so this doesn't need to be either. I have > no problem adding a new non-exception derived singleton to mark this. And > while __NoException__ may be a little confusing, something like __NoCause__ > reads great and can't be mistaken for a raiseable exception. The problem I have with names like __NoException__, __NoCause__, __NoWhatever__ is that is sounds a lot like None -- in otherwords, like there won't be any chaining. > So your example would then be: > > try: > try: > raise IndexError() > except: > raise CustomError() from None > except CustomError as e: > # nevermind, let's see the whole thing after all > raise e from __NoCause__ If we do switch from Ellipsis to something else I think a name like __Chain__ would be more appropriate. Or __ExcChain__. raise e from __ExcChain__ Less cute, but probably less confusing. ~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4