[Python-Dev] PEP 352 Transition Plan

[Brett Cannon]

On 10/28/05, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
> > > Why would a
> > > release allow catching something that cannot be raised?  I must be
> > > missing something here.
> >
> > So conforming code can catch exceptions raised by not-yet conforming
> code.
>
> That makes sense.
>
> What was the rationale for pushing the deprecation of __getitem__ and
> args back to Py2.8?  Is the there a disadvantage for doing it earlier?
> On the flip side, is there any reason it has to be done at all prior to
> Py3.0?  That change seems orthogonal to the rest of the proposal and has
> its own pluses and minuses (simplification on the plus-side and
> code-breakage on the minus-side).
>

I thought that there was no exact rush on their removal.  And I
suspect the later versions of the 2.x branch will be used to help ease
transition to Python 3, so I figured pushing it to 2.8 seemed like a
good idea.  I could even push it all the way to 2.9 if people prefer.

> FWIW, the args tuple does have a legitimate use case as one solution to
> the problem of exception chaining (keeping the old info intact, but
> adding new info as an extra field):
>
>    try:
>         raise TypeError('inner detail')
>    except TypeError, e:
>         args = e.args + ('outer context',)
>         raise TypeError(*args)
>

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.

-Brett