[Python-Dev] readd u'' literal support in 3.3?

[Vinay Sajip]

Terry Reedy <tjreedy <at> 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