On 21/01/2007 20.50, Tony Lownds wrote: > What's the cost of keeping sys.exc_info() on 3.0? 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.
It's been stated many times that making it possible to have a single codebase for both 2.x and 3.0 is *not* a goal of the Python 3.0 project. What it is more likely to happen is that it will be possible to maintain a codebase which runs under 2.x and can be automatically converted to a 3.0-compatible codebase. This will be possible through some (all?) of the following utilities (nothing is set in stone at this point): - A "-3" command line option in Python 2.x which turns on DeprecationWarnings on any construct that will go away in 3.x - A "from __future__ import py3k" to activate special Py3k constructs (like new keywords) in 2.x. - The addition of Py3k "features" to Python 2.x, in the cases where it does not hinder 2.x maintenance too much (eg: new names for modules/packages in stdlib). - The 2to3 refactoring tool: a program to automatically convert Python 2.x source code to Python 3.x source code (an initial version is already available in the sandbox). -- Giovanni Bajo _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
