[Python-ideas] Implicit string literal concatenation considered harmful?

[Ian Cordasco]

On Sat, May 11, 2013 at 12:48 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sun, May 12, 2013 at 2:37 AM, Christian Tismer <tismer at stackless.com> wrote:
>
>> So if there was some notation (not specified yet how) that triggers correct
>> indentation at compile time without extra functional hacks, so that
>>
>>     long_text = """
>>       this text is left justified
>>         and this line indents by two spaces
>>       """
>>
>> is stripped the leading and trailing \n and indentation is justified,
>> then I think the need for the implicit whitespace operator would be small.
>
> Through participating in this thread, I've realised that the
> distinction between when I use a triple quoted string (with or without
> textwrap.dedent()) and when I use implicit string concatenation is
> whether or not I want the newlines in the result. Often I can avoid
> the issue entirely by splitting a statement into multiple pieces, but
>
> I think Guido's right that if we didn't have implicit string
> concatenation there's no way we would add it ("just use a triple
> quoted string with escaped newlines" or "just use runtime string
> concatenation"), but given that we *do* have it, I don't think it's
> worth the hassle of removing it over a bug that a lint program should
> be able to pick up.
>
> So I'm back to where I started, which is that if this kind of problem
> really bothers anyone, start thinking seriously about the idea of a
> standard library linter.

Really this should be trivial for all of the linters that already
exist. That aside, (and this is not an endorsement for this proposal)
but can you not just do

    long_text = """\
       this is left justified \
       and this is continued on the same line
          and this is indented by two spaces
    """
I'm personally in favor of not allowing the concatenation to be on the
same line but allowing it across multiple lines. While linters would
be great for this, why not just introduce the SyntaxError since (as
has already been demonstrated) some of the concatenation already
happens at compile time.