[Python-3000] Exceptions internals and removing sys.exc_*
Brett Cannon
brett at python.org
Mon Jan 22 03:43:42 CET 2007
On 1/21/07, Tony Lownds <tony at pagedna.com> wrote:
>
> On Jan 21, 2007, at 10:57 AM, Brett Cannon wrote:
>
> > On 1/21/07, Tony Lownds <tony at pagedna.com> wrote:
> >>
> >> On Jan 20, 2007, at 9:46 PM, Collin Winter wrote:
> >>
> >> > Guido has mentioned [1] that since exceptions will be growing a
> >> > __traceback__ attribute in Python 3, it should be possible to
> >> remove
> >> > sys.exc_info().
> >>
> >> I hope that doesn't happen. sys.exc_info() is the only way to
> >> write code
> >> using exception values that will run on both 2.5 and 3.0.
> >>
> >> except Exception:
> >> e = sys.exc_info()[1]
> >>
> >
> > As has been stated on python-dev, 3.0 will not be hindered by
> > backwards-compatibility. 2.6 is going to be the version that has both
> > 2.x and 3.0 features to allow for transitioning.
> >
>
> Not allowing 3.0 to be hindered is reasonable, as long as its not a
> blind absolute.
That's fine, as long as the change is for the better. Moving the
traceback to exceptions is an improvement. That also means that
sys.exc_info is redundant and thus does not need to be kept around.
> ISTM that backwards compatability ought to be weighed, with a strong
> bias towards
> freedom to change in 3.0.
It is. There is a reason why we didn't rename a bunch of exceptions
to make their names better. It was stated that the change from the
2.x to the suggested 3.0 way was minimal and thus not worth it. But
the gains of moving the traceback to exceptions has been deemed worth
it.
> Check out this post:
>
> http://mail.python.org/pipermail/python-dev/2007-January/070665.html
>
> What's the cost of keeping sys.exc_info() on 3.0?
The same cost of keeping any redundant, not-as-nice API for anything
else we improve. There is maintenance costs along with educating
people on two different APIs for the same thing. TOOWTDI exists for a
reason.
> If that cost is a
> hindrance on 3.0, then
> fine, sys.exc_info() and the ability for module authors to use a
> single codebase on 2.x and
> 3.0 can be given up.
>
> If sys.exc_info() is not a hindrance to keep, why would we want to
> increase incompatibility?
>
3.0 is our chance to clean things up, not just do some small
improvement to the language. If we are going to take the time to
improve things it should be done completely and done well.
> Maybe I'm misreading that post. I'm not trying to cherry pick posts
> or play word games; I just
> feel that the loss of the possibility of a single codebase on <=2.5
> and 3.0 should not be given
> up lightly.
It's not being done lightly. But when something as obvious as moving
the traceback to exceptions presents itself and it means that another
way becomes antiquated we should take the chance to ditch the old way
so we don't have this weird situation of supporting both and old way
we discourage and a new way that we are pushing.
I understand the worry, Tony, but this has been argued on python-dev
and this worry has been made abundantly clear. But the decision has
been made that 2.6 will be the first version that can run both 2.5
code and a good chunk of 3.0 code and that is explicitly so that 3.0
does not have to worry about 2.5 compatibility.
Anyway, this discussion of transitioning has/is gone on python-dev and
I am getting burned out on it, so I am just going to stay out of the
rest of this thread (nothing personal, Tony).
-Brett
More information about the Python-3000
mailing list