[Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement (original) (raw)

Gustavo Carneiro gjcarneiro at gmail.com
Sat Sep 5 19:14:53 CEST 2015

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>

More information about the Python-Dev mailing list