Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Mark Lawrence <breamoreboy@yahoo.co.uk>
Newsgroups: comp.lang.python
Subject: Re: Pyhon 2.x or 3.x, which is faster?
Date: Sat, 12 Mar 2016 10:51:29 +0000
Lines: 62
Message-ID: <mailman.33.1457779939.12893.python-list@python.org>
References: <mailman.238.1457265255.20602.python-list@python.org> <mailman.45.1457453433.15725.python-list@python.org> <nbn871$8np$1@dont-email.me> <56df6761$0$1588$c3e8da3$5496439d@news.astraweb.com> <mailman.72.1457512871.15725.python-list@python.org> <nbp36e$560$1@dont-email.me> <mailman.96.1457558042.15725.python-list@python.org> <nbqaja$5g5$1@dont-email.me> <mailman.98.1457566570.15725.python-list@python.org> <nbqgmi$mha$1@dont-email.me> <mailman.108.1457595070.15725.python-list@python.org> <nbrms1$26p$1@dont-email.me> <mailman.123.1457612163.15725.python-list@python.org> <nbrq7b$eeu$1@dont-email.me> <mailman.127.1457615320.15725.python-list@python.org> <nbrvpj$5lm$1@dont-email.me> <mailman.149.1457638067.15725.python-list@python.org> <56e2579e$0$1608$c3e8da3$5496439d@news.astraweb.com> <nbv496$e8q$1@dont-email.me> <mailman.10.1457733601.12893.python-list@python.org> <nbvgds$ed$1@dont-email.me> <MSREy.1473117$wX5.1467333@fx40.am4> <nc0r0q$srq$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <nc0r0q$srq$1@dont-email.me>
Precedence: list
Xref: csiph.com comp.lang.python:104689

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