[Python-Dev] PEP 352 Transition Plan
bcannon at gmail.com
Sat Oct 29 00:52:48 CEST 2005
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
> 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):
> 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:
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.
More information about the Python-Dev