Article on the future of Python

[Terry Reedy]

On 9/27/2012 5:33 AM, Steven D'Aprano wrote:

> Nevertheless, I think there is something here. The consequences are nowhere
> near as dramatic as jmf claims, but it does seem that replace() has taken a
> serious performance hit. Perhaps it is unavoidable, but perhaps not.
>
> If anyone else can confirm similar results,

I already did, about a month ago, for windows. I think the actual 
problem is with find, not replace (which does a find before the 
replace). When I asked on pydev, Victor Stinner had no explanation, but 
said he might look into it eventually. Others thought it not terribly 
important since 7 times blazingly fast is still fast (in your example, 
29 versus 3 microseconds per operation.

jmf wrapping a possible real issue with anti-3.3 crud did not help in 
getting attention to the regression.

I also reported results of running stringbench.py on both 3.2 and 3.3 on 
windows. Overall, Unicode is nearly as fast as bytes and 3.3 as fast as 
3.2. Find/replace is the notable exception in stringbench, so it is an 
anomaly. Other things are faster in 3.3.

> I think this should be raised as a performance regression.

I agree, and Mark did it.

-- 
Terry Jan Reedy