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 <gu...@python.org> wrote: On Sat, Sep 5, 2015 at 1:44 AM, haypo s <victor.stin...@gmail.com> wrote: 2015-09-05 5:01 GMT+02:00 Guido van Rossum <gu...@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@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>
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
