[Python-3000] Exceptions internals and removing sys.exc_*

Phillip J. Eby pje at telecommunity.com
Tue Jan 23 03:44:18 CET 2007


At 03:10 PM 1/22/2007 -0600, Collin Winter wrote:
>Is there a reason why these API could not be defined in terms of a
>single exception object? In Python 3, all the information from a
>sys.exc_info() tuple  available from an exception instance: (type(e),
>e, e.__traceback__)
>
>As for documentation issues, I would think changing from a
>sys.exc_info() tuple to a single exception object would improve the
>language.
[example snipped]

Um, you're not taking 2.6 into consideration here.  Remember that there has 
to be a way to spell all these APIs in 2.6 that will still work in 3.0.  So 
the way the docs would actually have to be rewritten, would be to specify 
how to tell whether an exc_info argument is a tuple or an exception 
instance, and how the code would need to be handled.

You also ignored my point regarding three-argument "raise" in Python 2.6, 
which is that it's (presumably) a SyntaxError in Python 3.0, which means it 
doesn't matter if you do something like:

     if exc.traceback is None:
          raise type(exc), exc, sys.current_traceback()
     else:
          raise exc

The code still won't work in 3.0 because of the mere presence of a 
3-argument raise.

Presumably, the solution will require setting .traceback explicitly and 
using 1-argument raise, resulting in some rather hellish-looking changes 
that are probably not going to be able to be automated by the refactoring 
tool, since it only knows about sys.exc_info() and raise.

I suppose it could rewrite 'raise a, b, c' as 'b.traceback =c; raise b', 
but it still needs to rewrite sys.exc_info() to something, like 
'type(sys.current_exception()), sys.current_exception(), 
sys.current_traceback())'.

IMO, this seems sufficient reason to keep sys.exc_info() around, since 
there *has* to be some way to access the current exception and traceback, 
that exists in *both* 2.6 and 3.0.  Otherwise, there is no way to write 
code that operates on the current exception and/or traceback.

(And again, in 2.6 we are going to have to clear the .traceback of the 
exception when it's caught by an old-style "except", so we can't just have 
a sys.current_exception(); there has to be a way to get the current 
traceback, separately.)



More information about the Python-3000 mailing list