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). > 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. > > 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. Regards Antoine. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
