[Python-3000] sys.exc_info()
Adam Olsen
rhamph at gmail.com
Sun Jun 1 00:28:15 CEST 2008
On Sat, May 31, 2008 at 2:03 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Adam Olsen <rhamph <at> gmail.com> writes:
>>
>> The bytecode generation for "raise" could be changed literally be the
>> same as "except Foo as e: raise e". Reuse our existing stack, not add
>> another one.
>
> As someone else pointed, there is a difference between the two constructs: the
> latter appends a line to the traceback while the former doesn't. I suppose in
> some contexts it can be useful (especially if the exception is re-raised several
> times because of a complex architecture, e.g. a framework).
Yeah. If anything it seems like a positive, not a negative.
>> The commented out raise should use the outer except block (and thus be
>> lexically based), but sys.exc_info() doesn't have to be.
>
> But would you object to sys.exc_info() being lexically based as well?
> I say that because the bare "raise" statement and sys.exc_info() use the same
> attributes internally, so they will have the same semantics unless we decide
> it's better to do otherwise.
I'm trying to eliminate complexity, paring it down to the bare minimum
of supported functionality. However, I was also confusing
sys.exc_info() with sys.last_*. That leads to another thought..
>> > Also, "yield" cannot blindingly clear the exception state, because the frame
>> > calling the generator may except the exception state to be non-None.
>> > Consequently, we might have to keep the f_exc_* members solely for the
>> > generator case.
>>
>> Why? Why should the frame calling the generator be inspecting the
>> exception state of the generator? What's the use case?
>
> You misunderstood me. The f_exc_* fields will be used internally to swap between
> the inner generator's exception state and the calling frame's own exception
> state. They will have no useful meaning for outside code so I suggest they are
> not accessible from Python code anymore.
Why not move f_exc_* into the PyTryBlock struct? We can eliminate the
per-thread exception and have sys.exc_info() search the stack for an
active except block. No need to swap anything because the stack is
always current.
(tstate->curexc_* would be unchanged of course, as it represents the
"hot" exception, not the last caught exception.)
--
Adam Olsen, aka Rhamphoryncus
More information about the Python-3000
mailing list