My statement wasn't clear enough. Rendering occurs if the string being concatenated is already a concatenation object created by an earlier assignment. In s = a + b + c + d + e + f , there would be rendering of the source string if it is already a concatenation. Here is an example that would make it clear: a = "Value a =" a += "anything" # creates a concatenation c = a + b #This would cause rendering of a and then c will become concatenation between a and b. c += "Something" # This will not append to the concatenation object, but cause rendering of c and then it will create a concatenation between c and "Something", which will be assigned to c. Now if there are a series of assignments, (1) s = c + "something" # causes rendering of c (2) s += a # causes rendering of s and creates a new concatenation (3) s += b # causes rendering of s and creates a new concatenation (4) s += c # causes rendering of s and creates a new concatenation (5) print s # causes rendering of s If there is list of strings created and then they are concatenated with +=, I would expect it to be slower because of the additional allocations involved in rendering. -Chetan On 10/18/06, Kristján V. Jónsson <kristjan at ccpgames.com> wrote: > > Doesn't it end up in a call to PyString_Concat()? That should return a > PyStringConcatenationObject too, right? > K > > ------------------------------ > > > Construct like s = a + b + c + d + e , where a, b etc. have been assigned > string values earlier will not benefit from the patch. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20061018/18e0c506/attachment.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4