I would have thought it would be a no-brainer to just ban it and insist on an explicit + operator. I'm pretty surprised that issue was so flippantly closed.

> I would have thought it would be a no-brainer to just ban it and insist on an explicit + operator.

Maybe as a matter of linting. As a matter of language design, I think + for string concatenation is a big mistake; using different symbols for numeric addition and string concatenation is something Perl got right.

Yes, I meant as a matter of linting. I can understand the arguments being different for the language as a whole, particularly when legacy compatibility is a consideration.

But my impression using pylint is that its default settings are wildly opinionated, hence the surprise that this wouldn't have fallen under that umbrella.

The PR has been merged (for lists and tuples and sets only).

https://github.com/PyCQA/pylint/pull/1655

can do a good job at allowing long urls for example, but would be whack a mole trying to cater for "all" purposeful implicit string concatenations

Splitting long URLs onto multiple lines because you have a hard line length limit is considerably more harmful than exceeding the length limit in such cases, because you break the URL up so that tooling (including language-unaware static analysers) can’t conveniently access it. (e.g. if you want to open the link, you can’t just copy it or click on it or whatever, but must first join the lines, removing the quotation marks.) Any tool that forcibly splits up such lines when there is no fundamental hard technical reason why it must is, I categorically state, a bad tool.