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

[Collin Winter]

On 1/22/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 06:43 PM 1/21/2007 -0800, Brett Cannon wrote:
> >But when something as obvious as moving
> >the traceback to exceptions presents itself and it means that another
> >way becomes antiquated we should take the chance to ditch the old way
> >so we don't have this weird situation of supporting both and old way
> >we discourage and a new way that we are pushing.
>
> How will this affect the __exit__ signature for context managers, which is
> defined in sys.exc_info() terms?  Also, WSGI defines certain
> exception-handling parameters in terms of sys.exc_info().
>
> In fact, many APIs define things in terms of sys.exc_info() tuples.  That
> doesn't mean they have to come from sys.exc_info(), of course, but these
> APIs are defined that way based on a standard feature of the langauge.  So,
> documenting them may be more awkward.

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. Let's try a passage from PEP 333:

"""
The exc_info argument, if supplied, must be a Python sys.exc_info()
tuple. This argument should be supplied by the application only if
start_response is being called by an error handler. If exc_info is
supplied, and no HTTP headers have been output yet, start_response
should replace the currently-stored HTTP response headers with the
newly-supplied ones, thus allowing the application to "change its
mind" about the output when an error has occurred.

However, if exc_info is provided, and the HTTP headers have already
been sent, start_response must raise an error, and should raise the
exc_info tuple. That is:

raise exc_info[0],exc_info[1],exc_info[2]
"""

changes to

"""
The exc argument, if supplied, must be a Python exception instance.
This argument should be supplied by the application only if
start_response is being called by an error handler. If exc is
supplied, and no HTTP headers have been output yet, start_response
should replace the currently-stored HTTP response headers with the
newly-supplied ones, thus allowing the application to "change its
mind" about the output when an error has occurred.

However, if exc is provided, and the HTTP headers have already been
sent, start_response must raise an error, and should raise the exc
object. That is:

raise exc
"""

> Will we also be dropping three-argument "raise"?

Yes. I have a new version of 2to3's raise fixer that is able to handle
both the two- and three-argument forms of "raise".

Thanks,
Collin Winter