On 13.02.13 19:06, Maciej Fijalkowski wrote:
On Wed, Feb 13, 2013 at 7:33 PM, MRAB email@example.com wrote:
On 2013-02-13 13:23, Lennart Regebro wrote:
On Wed, Feb 13, 2013 at 1:10 PM, Serhiy Storchaka firstname.lastname@example.org wrote:
I prefer "x = '%s%s%s%s' % (a, b, c, d)" when string's number is more than 3 and some of them are literal strings.
This has the benefit of being slow both on CPython and PyPy. Although using .format() is even slower. :-)
How about adding a class method for catenation:
str.cat(a, b, c, d) str.cat([a, b, c, d]) # Equivalent to "".join([a, b, c, d])
Each argument could be a string or a list of strings.
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
I actually wonder.
There seems to be the consensus to avoid += (to some extent). Can someone commit the change to urrllib then? I'm talking about reverting http://bugs.python.org/issue1285086 specifically
So _is_ += faster in certain library funcs than ''.join() ? If that's the case, the behavior of string concat could be something that might be added to some implementation info, if speed really matters.
The library function then could take this info and use the appropriate code path to always be fast, during module initialisation. This is also quite explicit, since it tells the reader not to use in-place add when it is not optimized.
If += is anyway a bit slower than other ways, forget it. I would then maybe add a commend somewhere that says "avoiding '+=' because it is not reliable" or something.
cheers - chris