On 10/28/05, Raymond Hettinger <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com