Pyhon 2.x or 3.x, which is faster?

[Mark Lawrence]

On 12/03/2016 10:31, BartC wrote:
> On 12/03/2016 10:06, alister wrote:
>> On Fri, 11 Mar 2016 22:24:45 +0000, BartC wrote:
>>
>>> On 11/03/2016 21:59, Mark Lawrence wrote:
>>>> On 11/03/2016 18:57, BartC wrote:
>>>
>>>> def test():
>>>>       s=""
>>>>       for i in range(10000000):
>>>>           s+="*"
>>>>       print (len(s))
>>>>
>>>> test()
>>>
>>>> The minor snag that you might like to correct with your microbenchmark,
>>>> which any experienced Python programmer knows, is that you *NEVER,
>>>> EVER*
>>>> create strings like this.
>>>
>>> Why not? Chris said his version runs much faster (even allowing for
>>> different machines), and might have a special optimisation for it.
>>>
>>> And I think it can be optimised if, for example, there are no other
>>> references to the string that s refers to.
>>>
>>> So what's wrong with trying to fix it rather that using a workaround?
>>
>> because the "workarround" is not a workarround it is the correct way to
>> do it
>> the code above is a workarround for somone who does not know the pythonic
>> method to do this
>>
>> S= "*"*10000000
>
> This is a benchmark that measures the cost of adding to a string a
> character at a time.
>
> In practice the final length of the string is not known, and the
> characters added at each stage are not known.
>
> Although the strings won't usually be that big; the benchmark
> exaggerates here to highlight a possible issue with += on strings. And
> it worked, as there can be big difference with or without the +=
> optimisation in place.
>
> It also showed a possible bug or problem with PyPy.
>
> You can't demonstrate all this by just writing s="*"*10000000.
>

There is no possible issue with += on strings, there is a known issue. 
What to do about has all ready been discussed by myself, Dennis Lee 
Bieber, Michael Torrie and Steven D'Aprano, but you've chosen to ignore 
what we've written.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence