RetroSearch Browse

Sat Sep 5 19:14:53 CEST 2015 · https://mail.python.org/pipermail/python-dev/2015-September/141460.html

Why not allow string concatenation without plus sign only if/when the
implementation becomes optimised to allow compile time concatenation?  This
makes it crystal clear whether the concatenation is compile time or
runtime. If we allow it now, it's hard to tell without looking at the
CPython source code...

On Sat, 5 Sep 2015 16:57 Guido van Rossum <guido at python.org> wrote:

On Sat, Sep 5, 2015 at 1:44 AM, haypo s <victor.stinner at gmail.com> wrote:

2015-09-05 5:01 GMT+02:00 Guido van Rossum <guido at python.org>:
> And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> holiday in the US) in case anything unforeseen comes up, but this is
really
> the Last Call for this PEP.

String concatenation is inefficient in Python because strings are
immutable. There is a micro-optimization which tried to reduce the bad
performances of a+b, but it's better to avoid it.

Python replaces >'abc' 'def'< with a single string >'abcdef'<. It's
done by the parser, there is no overhead at runtime.

PEP 498 allows to write >'abc' f'string'< which is replaced with
>'abc' 'string'.__format__()< whereas str+str is a bad practice.

I would prefer to force users to write an explicit '+' to remind them
that there are more efficient ways to concatenate strings like
''.join((str1, str2)) or putting the first string in the f-string:
>f'abcstring'<.

Section in the PEP:
https
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>://
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>
www.python.org
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>/dev/
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>
pepsstring
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>
/pep-0498/#concatenating-strings
<https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings>

Victor

What does the extra + buy users? It's just more punctuation noise. The
implementation is intentionally left unspecified by the PEP; it should be
possible to design an implementation that combines all the parts together
more efficiently than the use of + (e.g. using a "string builder" object
internally).

-- 

--Guido van Rossum (python.org <http://python.org/~guido>/~
<http://python.org/~guido>guido <http://python.org/~guido>)

_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https <https://mail.python.org/mailman/listinfo/python-dev>://
<https://mail.python.org/mailman/listinfo/python-dev>mail.python.org
<https://mail.python.org/mailman/listinfo/python-dev>/mailman/
<https://mail.python.org/mailman/listinfo/python-dev>listinfo
<https://mail.python.org/mailman/listinfo/python-dev>/
<https://mail.python.org/mailman/listinfo/python-dev>python-dev
<https://mail.python.org/mailman/listinfo/python-dev>
Unsubscribe: https
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
://
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
mail.python.org
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
/mailman/options/
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
python-dev
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>/
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
gjcarneiro%40gmail.com
<https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150905/ee82b665/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2015-September/141460.html below:

Literal String Interpolation is ready for pronouncement