On Sat, Apr 11, 2015 at 5:54 AM, Travis Everett
I have a specialized use case for exceptions which need to analyze their __cause__ property before they're fully initialized. The property isn't set until after init, and (forgive my ignorance of Python's source!) appears to be done at the C level in a way that it can't be observed with a property setter or __setattr__. I currently create a method to do this post-init work as a workaround, and push the burden of making sure it gets called on the code using the exceptions--but this makes the exceptions idiomatic and error-prone.
On principle I'd be in favour of making the setting of __cause__ go through the normal mechanisms, such that @property etc would work; but just out of curiosity, what would happen if your code raised an exception during the raising of another exception? Because that's when __cause__ will get set - the new exception object is fully constructed, and now it goes into exception handling to start bubbling up. Could be a bit weird! But if that's handlable (maybe it just chains yet another exception in), then that's the route I'd be inclined towards. There are quite a few things that happen somewhat weirdly in Python, largely (I think) because of specific CPython optimizations or implementation details. Anything that makes the language more flexible may well have a hefty performance cost, but if it doesn't, then it would be a good thing IMO. ChrisA