[Python-Dev] readd u'' literal support in 3.3? (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Fri Dec 9 02:39:39 CET 2011

Terry Reedy <tjreedy udel.edu> writes:

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?

It's not the speed of 2to3 per se; this seems very reasonable for a tool of its type. It's the overall process, which currently involves running 2to3 on an entire codebase (for example, using setup.py with flags to run 2to3 during setup). With a large project like Django, and hundreds or thousands of source files, 2to3 used in this way is on a hiding to nothing; no amount of profiling and tweaking is likely to lead to acceptable turnaround.

However, 2to3 tools could be developed which are based on 2to3/lib2to3 and are incremental in nature; then as you edit and save a file, its processed version could be available very shortly afterwards (since we only need to translate the file that was saved) - this would be even quicker in an IDE where the 2to3 code (and perhaps the AST of files being worked on) could remain loaded in memory over an entire development session. That, along with some more/smarter fixers, could go some way to addressing the "too slow" issue.

Regards,

Vinay Sajip

More information about the Python-Dev mailing list