3 ms·

Seems expected, as linters can't be sure when it's not intentional. Like this request to pylint: https://github.com/PyCQA/pylint/issues/1589 https://github.co

by tyingq 5y ago

Seems expected, as linters can't be sure when it's not intentional. Like this request to pylint: https://github.com/PyCQA/pylint/issues/1589 https://github.com/PyCQA/pylint/issues/1589 Is there usually enough context for a linter to make an educated guess?

mikepurvis 5y ago
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.
- thaumasiotes 5y ago
  > 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.
  - mikepurvis 5y ago
    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.
- ReleaseCandidat 5y ago
  The PR has been merged (for lists and tuples and sets only). https://github.com/PyCQA/pylint/pull/1655 https://github.com/PyCQA/pylint/pull/1655
rikatee 5y ago
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
- chrismorgan 5y ago
  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.

by tyingq 5y ago

mikepurvis 5y ago

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.

thaumasiotes 5y ago
> 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.
- mikepurvis 5y ago
  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.
ReleaseCandidat 5y ago
The PR has been merged (for lists and tuples and sets only). https://github.com/PyCQA/pylint/pull/1655 https://github.com/PyCQA/pylint/pull/1655

rikatee 5y ago

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

chrismorgan 5y ago
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.