On 13.02.13 19:06, Maciej Fijalkowski wrote:
On Wed, Feb 13, 2013 at 7:33 PM, MRAB <pyt...@mrabarnett.plus.com> wrote:
On 2013-02-13 13:23, Lennart Regebro wrote:
On Wed, Feb 13, 2013 at 1:10 PM, Serhiy Storchaka <storch...@gmail.com>
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
--
Christian Tismer :^) <mailto:tis...@stackless.com>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776 fax +49 (30) 700143-0023
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
_______________________________________________
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/archive%40mail-archive.com
