[Python-Dev] PEP 352 Transition Plan
bcannon at gmail.com
Sat Oct 29 05:37:29 CEST 2005
On 10/28/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
> > Interesting point, but I think that chaining should have more concrete
> > support ala PEP 344 or some other mechanism. I think most people
> > agree that exception chaining is important enough to have better
> > support than some implied way of a causing exception to be passed
> > along. Perhaps something more along the lines of:
> > try:
> > raise TypeError("inner detail")
> > except TypeError, e:
> > raise TypeError("outer detail", cause=e)
> > where BaseException then has a 'cause' attribute that is set to None
> > by default or some specific object that is passed in as the second
> > argument to the constructor.
> Another point in PEP 352's favour, is that it makes it far more feasible to
> implement something like PEP 344 by providing "__traceback__" and
> "__prev_exc__" attributes on BaseException.
> The 'raise' statement could then take care of setting them appropriately if it
> was given an instance of BaseException to raise.
Yep. This is why having a guaranteed API is so handy for exceptions.
And actually PEP 3000 says that exceptions are supposed to gain a
traceback attribute. But that can be another PEP if PEP 344 doesn't
> Actually, that brings up another question - PEP 352 says it will require
> objects that "inherit from BaseException". Does that mean that either subtypes
> or instances of BaseException will be acceptable? Or does it just mean
> instances? If the latter, how will that affect the multi-argument forms of
I don't see how a multi-argument 'raise' changes the situation any.
``raise BaseException`` and ``raise BaseException()`` must both be
supported which means isinstance() or issubtype() will be used (unless
Python 3 bans raising a class or something).
More information about the Python-Dev