On 12/8/2011 10:53 AM, Jannis Leidel wrote:
possible at all). That means to reduce the number of hacks needed and thoroughly reviewing to not suddenly lead into a maintenance dead end. E.g. I'm still not sure the one codebase strategy is better than the 2to3 strategy.
One codebase with version compatibility hacks and no use of 2to3 is one pure strategy. Two codebases with no compatibility hacks (at least for 2 versus 3) and use of 2to3 to bridge all differences is another. Perhaps we need something in between, with a mix of compatibility hacks and automatic 2to3 conversions that has not been discovered yet, or that can be customized on a project by project basis.
Deleting 'u' prefixes from string literals is something that is easy to do with 2to3 for anyone who cannot use the future import because of supporting 2.5.
More that one person has said that *any* use of 2to3 is impractical for rapid-turnaround development because 2to3 is 'too slow'. If so, have the usual methods for speeding up a Python program been applied? Has anyone profiled 2to3? Is most of the time spent in 2to3 itself or some particular module that it uses? Is the time that is spend in 2to3 itself a result of the overall framework or particular fixers? If the latter, can slow fixers be eliminated by using a compatibility hack in the Python 2 code? Has anyone tried to compile 2to3 and prerequisite Python-coded modules?
-- Terry Jan Reedy _______________________________________________ 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
