Article on the future of Python

[Mark Lawrence]

On 27/09/2012 20:08, Terry Reedy wrote:
> 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.
>

http://bugs.python.org/issue16061 and you should read it.  I've tried to 
really muddy the waters by opening this issue, and the python devs are 
giving out facts, how dare they!!!  It's just not my day is it? :(

-- 
Cheers.

Mark Lawrence.