On 1/22/07, Phillip J. Eby <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
