Giovanni Bajo wrote: > Steven D'Aprano wrote: > > >>But the real killer is this one line: >> >>row=row+chr(num/64) >> >>Bad, bad BAD idea. Every time you add two strings together, Python >>has to copy BOTH strings. As row gets huge, this takes longer and >>longer to do. > > > This is no longer true as of CPython 2.4 though. I'm not sure which version > the > OP was using because he didn't say.
No, that's not correct. You are making a false assumption. This is from the "What's New" for Python 2.4: [quote] String concatenations in statements of the form s = s + "abc" and s += "abc" are now performed more efficiently in certain circumstances. This optimization won't be present in other Python implementations such as Jython, so you shouldn't rely on it; using the join() method of strings is still recommended when you want to efficiently glue a large number of strings together. [end quote] Note the "more efficiently in CERTAIN CIRCUMSTANCES" [emphasis added]? That certainly does not mean that concatenating large numbers of strings is no longer slow. It just means that *sometimes* (almost always? often? occasionally?) it isn't as slow as it used to be. We really don't know what the optimization recognises, how it works, or how fast a difference it makes. Writing poor code, and trusting an implementation- specific optimization to make it run "faster" (how much faster?) is always a dangerous strategy. Better to avoid the temptation if you can, appreciate the improved performance for those times when you do string concatenation, but continue to use the join method anytime you are adding large numbers of strings. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
