On 12 December 2012 07:52, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
> John Gordon wrote: > > def encode(plain): > > '''Return a substituted version of the plain text.''' > > encoded = '' > > for ch in plain: > > encoded += key[alpha.index(ch)] > > return encoded > > Terry Reedy <tjre...@udel.edu> wrote: > >The turns an O(n) problem into a slow O(n*n) solution. Much better to > >build a list of chars and then join them. > > There have been much better suggestions in this thread, but John Gordon's > code above is faster than the equivilent list and join implementation > with Python 2.6 and Python 3.1 (the newest versions I have handy). > CPython optimized this case of string concatenation into O(n) back in > Python 2.4. > >From "What's New in Python 2.4": http://docs.python.org/release/2.4.4/whatsnew/node12.html#SECTION0001210000000000000000 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. Emphasis mine. The optimisation was added to improve the situation for programs that were already using the anti-pattern of string concatenation, not to encourage people to use it. As a real-world case, a bug was recently found in Mercurial where an operation on Windows was taking orders of magnitudes longer than on Linux due to use of string concatenation rather than the join idiom (from ~12 seconds spent on string concatenation to effectively zero). Tim Delaney
-- http://mail.python.org/mailman/listinfo/python-list
