On Sat, May 11, 2013 at 12:48 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On Sun, May 12, 2013 at 2:37 AM, Christian Tismer <tismer@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.