Message152242
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. |
|
Date |
User |
Action |
Args |
2012-01-29 15:50:56 | poke | set | recipients:
+ poke, georg.brandl, rhettinger, ncoghlan, pitrou, draghuram, aronacher, ezio.melotti, eric.araujo, mrabarnett, steven.daprano, ethan.furman, catalin.iacob |
2012-01-29 15:50:55 | poke | set | messageid: <1327852255.94.0.110946606175.issue6210@psf.upfronthosting.co.za> |
2012-01-29 15:50:55 | poke | link | issue6210 messages |
2012-01-29 15:50:55 | poke | create | |
|