This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author poke
Recipients aronacher, catalin.iacob, draghuram, eric.araujo, ethan.furman, ezio.melotti, georg.brandl, mrabarnett, ncoghlan, pitrou, poke, rhettinger, steven.daprano
Date 2012-01-29.15:50:55
SpamBayes Score 4.187722e-09
Marked as misclassified No
Message-id <1327852255.94.0.110946606175.issue6210@psf.upfronthosting.co.za>
In-reply-to
Content
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. In the original example, I want to completely replace the “context” by a new exception without implicitely keeping over the original exception.

So even if using `from None` will prevent the context from being displayed (as the explicitely set cause will override it), the `__context__` will probably still be set by the `raise` statement, and I think that shouldn’t happen. Hence the `raise X instead` or `raise as X` idea that simply does not set the context but “destroys” it.
History
Date User Action Args
2012-01-29 15:50:56pokesetrecipients: + poke, georg.brandl, rhettinger, ncoghlan, pitrou, draghuram, aronacher, ezio.melotti, eric.araujo, mrabarnett, steven.daprano, ethan.furman, catalin.iacob
2012-01-29 15:50:55pokesetmessageid: <1327852255.94.0.110946606175.issue6210@psf.upfronthosting.co.za>
2012-01-29 15:50:55pokelinkissue6210 messages
2012-01-29 15:50:55pokecreate