[code-quality] How to detect unused PyLint declarations

[Ned Batchelder]

On 11/22/14 4:02 AM, Kay Hayen wrote:
>
> Hello there,
>
> I have deployed that, in my check-with-pylint on the factory git 
> branch, I am now
> for the first time ever, in Nuitka, fully pylint clean with PyLint1.3.
>
> What that message above does, is to make PyLint very version 
> dependent. There are new messages to that version, and there are fixed 
> false alarms and new false alarms. But there is no way around that, right?
>
> As a tool for distributed development, that's not ideal. Say I would 
> want to make these checks part of commit hooks, I would require people 
> to have 1.3 somewhere, when they already have 1.4, or still 1.2, you 
> get the idea.
Wouldn't you pin the version of PyLint in your requirements.txt file?
>
> Or do I still get to implement the "delta of PyLint warnings didn't 
> worsen" check for that commit hook, even though I am supposedly now 
> PyLint clean. Seems there is no real way around that?
BTW, diff-cover is a tool that can give you coverage, pep8, and pylint 
measurements just for your changes, rather than for the entire source 
tree that results from your changes.  It's a good way to focus 
developers on improving quality metrics.

--Ned.
>
> Yours,
> Kay
>
>
> 2014-11-21 23:12 GMT+01:00 Torsten Marek <shlomme at gmail.com 
> <mailto:shlomme at gmail.com>>:
>
>     Yes, I0021 is useless-suppression.
>
>     There's also suppressed-message, to show what kinds of messages
>     have been suppressed. Looking at that every once in a while is
>     interesting as well. Especially for badly understood messages,
>     there is a tendency in developers to just paper over the warnings
>     instead of fixing the underlying issue.
>
>     // Torsten
>
>     2014-11-21 18:32 GMT+01:00 Anne Mulhern <amulhern at redhat.com
>     <mailto:amulhern at redhat.com>>:
>
>
>
>
>
>         ----- Original Message -----
>         > From: "Kay Hayen" <kay.hayen at gmail.com
>         <mailto:kay.hayen at gmail.com>>
>         > To: code-quality at python.org <mailto:code-quality at python.org>
>         > Sent: Wednesday, October 29, 2014 10:00:15 AM
>         > Subject: [code-quality] How to detect unused PyLint declarations
>         >
>         >
>         > Hello,
>         >
>         > I have coding rules that require me to annotate exceptions
>         to rules
>         > for PyLint, but occasionally it happens that I find PyLint
>         rules disabled
>         > that would no longer be necessary.
>         >
>         > Is there a way or script, or anything to detect these
>         automatically? I
>         > was thinking of writing something that removes PyLint
>         disablers one
>         > by one, and checks if that doesn't generate PyLint warnings, and
>         > warn about those. Didn't do it so far, but I feel tempted to
>         do this
>         > now.
>         >
>         > However, to PyLint, this might be way more easier to
>         implement, and
>         > maybe it was done. I cannot find anything in the manpage though.
>         >
>         > Yours,
>         > Kay
>         >
>         > _______________________________________________
>         > code-quality mailing list
>         > code-quality at python.org <mailto:code-quality at python.org>
>         > https://mail.python.org/mailman/listinfo/code-quality
>         >
>
>         This is something I am interested in as well.
>
>         It looks like the I0021: Useless suppression of %s warning
>         should report those cases.
>
>         - mulhern
>         _______________________________________________
>         code-quality mailing list
>         code-quality at python.org <mailto:code-quality at python.org>
>         https://mail.python.org/mailman/listinfo/code-quality
>
>
>
>
>
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20141122/1308d5f6/attachment.html>