On 1/21/07, Tony Lownds <[EMAIL PROTECTED]> wrote: > > On Jan 21, 2007, at 10:57 AM, Brett Cannon wrote: > > > On 1/21/07, Tony Lownds <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
