On Sun, Mar 19, 2017 at 7:24 PM, Pavol Lisy <pavol.l...@gmail.com> wrote:
> On 3/19/17, Chris Angelico <ros...@gmail.com> wrote:
>> On Sun, Mar 19, 2017 at 4:53 PM, Pavol Lisy <pavol.l...@gmail.com> wrote:
>
>>> In case of spaces there is not discrepancy. pep8 and similar linters
>>> could work fine without incompatible configurations.
>
>> I don't like the pep8 tool; its name implies far more authority than
>> it actually has. But if you look at the rules Python 3 applies, or
>> Python 2 with "-tt", you should easily be able to comply.
>
> There was discussion on python-idea about duplicity in dict definition.
>
> {"a": "foo", "a": "bar"}
>
> Conclusion was that it is not an error and anybody could use linters
> for finding it. For example pylint could do it. Modern editors could
> do linting parallel to editing and many people use it.
>
> I think - I couldn't like everything what pep8 or pylint or any others
> do. But it is some kind of responsibility to write codes, which do not
> produce plenty of warnings. (because they could hide warning like
> duplicity in dict)
>
> And I think that significance of linters could grow as machine
> learning will evolve. So if there is something wrong about PEP-8 maybe
> there is some work for us to improve it.
I'm not sure what your point is, or why you're responding to my post
to make it, so I'll clarify what I was saying:
The tool "pep8" is inappropriately named. No linter should use this
name. It implies a level of authority by linking with a very specific
document.
Now, the tool itself may well be a brilliant linter. That's fine, and
linters are excellent. But saying "a linter should be able to catch
this error" should not have people immediately turn around and say
"then PEP 8 should have a rule about this". And that's what seems to
happen when the tool and the document are too tightly linked.
http://rosuav.blogspot.com/2016/04/falsehoods-programmers-believe-about.html
PEP 8 is a very specific-purpose document: it is a set of rules which
govern the Python standard library. It so happens that, like many
other style guides, it can be adopted for other projects (just as the
airbnb style guide is adopted by a lot of JavaScript projects, and the
GNU style guide can be used for non-GNU projects), but it's still a
document aimed at humans. Here is its most important section:
https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds
Start by disconnecting the style guide from the linter. A piece of
code may fulfil every rule in your guide, but still be flagged by the
linter; or it can pass the linter's check, but still fail code review
because it violates a rule of style. (Example of the latter:
inconsistent naming of similar concepts. No linter can understand that
X.foo and Y.bar mean the same thing.) Enhancements to the style guide
and enhancements to the linter are thus completely independent, and
serve different (though related) purposes.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
