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

Phillip J. Eby pje at telecommunity.com
Mon Jan 22 17:11:03 CET 2007


At 10:44 AM 1/22/2007 -0500, Jim Jewett wrote:
>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 ... should take the chance to ditch the old way
>
>>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().
>
>They can refer to python 2.x, which will still have it.
>They can be explicit, and mention a 3-tuple of exception (type, value,
>traceback).
>
>They should grow an alternate interface that just takes an exception instance.

Changing __exit__ would be a language change, and presumably requires a new 
or updated PEP, as would a change to WSGI.  Likewise the changes to the 
logging API.


>>Will we also be dropping three-argument "raise"?
>
>Is there any reason not to drop it?

How would you perform a three-argument raise in Python 2.6?  We can't add 
the traceback to exception objects in 2.6 without creating dangerous 
traceback reference cycles for 2.x code, at least not without some other 
sort of as-yet-undetermined magic, like temporarily removing and re-adding 
the traceback attribute to exceptions caught in old-style except: clauses.

I guess my point is that if we're going down this road, we need to figure 
out how we're going to add comparable features to 2.6.

I suppose, we could have old-style "except t, e:" clauses set the exception 
object's traceback attribute to None, so that old code would never see 
it.  Likewise, using sys.exc_info() or any other old-style exception access 
could do the same thing.

Somebody needs to come up with an idea for how to handle 
__exit__().  Currently, it requires all three arguments, but it sounds like 
you suggest it change to just one in Py3K.  I guess that 2.6 code could set 
default values of None for the value and traceback arguments, and 2.6 would 
still pass those values in.  The body of the __exit__ method would have to 
check on those, to avoid passing them to APIs that don't take them in 3.0.

(By the way, we *still* need a way to get the current active exception, 
regardless of how the API is spelled.  See the contextlib module's 
generator decorator for one example of why.)



More information about the Python-3000 mailing list