Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #72263 > unrolled thread

pyflakes best practices?

Back to article view | Back to comp.lang.python

Contents

  pyflakes best practices? Roy Smith <roy@panix.com> - 2014-05-29 20:13 -0400
    Re: pyflakes best practices? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-30 01:50 +0100
      Re: pyflakes best practices? Roy Smith <roy@panix.com> - 2014-05-29 21:14 -0400
        Re: pyflakes best practices? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-31 18:10 +0100
    Re: pyflakes best practices? Roland Koebler <r.koebler@yahoo.de> - 2014-06-04 17:35 +0200
    Re: pyflakes best practices? Miki Tebeka <miki.tebeka@gmail.com> - 2014-06-04 22:12 -0700

#72263 — pyflakes best practices?

We've recently started using pyflakes.  The results seem to be similar 
to most tools of this genre.  It found a few real problems.  It 
generated a lot of noise about things which weren't really wrong, but 
were easy to fix (mostly, unused imports), and a few plain old false 
positives which have no easy "fix" (in the sense of, things I can change 
which will make pyflakes STFU).

So, what's the best practice here?  How do people deal with the false 
positives?  Is there some way to annotate the source code to tell 
pyflakes to ignore something?

[toc] | [next] | [standalone]

#72268

On 30/05/2014 01:13, Roy Smith wrote:
> We've recently started using pyflakes.  The results seem to be similar
> to most tools of this genre.  It found a few real problems.  It
> generated a lot of noise about things which weren't really wrong, but
> were easy to fix (mostly, unused imports), and a few plain old false
> positives which have no easy "fix" (in the sense of, things I can change
> which will make pyflakes STFU).
>
> So, what's the best practice here?  How do people deal with the false
> positives?  Is there some way to annotate the source code to tell
> pyflakes to ignore something?
>

I was under the impression that pyflakes was configurable.  It it isn't 
I'd simply find another tool.  Having said that if you don't get better 
answers here try gmane.comp.python.code-quality.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#72269

In article <mailman.10467.1401411041.18130.python-list@python.org>,
 Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:

> On 30/05/2014 01:13, Roy Smith wrote:
> > We've recently started using pyflakes.  The results seem to be similar
> > to most tools of this genre.  It found a few real problems.  It
> > generated a lot of noise about things which weren't really wrong, but
> > were easy to fix (mostly, unused imports), and a few plain old false
> > positives which have no easy "fix" (in the sense of, things I can change
> > which will make pyflakes STFU).
> >
> > So, what's the best practice here?  How do people deal with the false
> > positives?  Is there some way to annotate the source code to tell
> > pyflakes to ignore something?
> >
> 
> I was under the impression that pyflakes was configurable.  It it isn't 
> I'd simply find another tool.  Having said that if you don't get better 
> answers here try gmane.comp.python.code-quality.

I didn't know that list existed, it looks very interesting.  Thanks for 
the pointer!

[toc] | [prev] | [next] | [standalone]

#72342

On 30/05/2014 02:14, Roy Smith wrote:
> In article <mailman.10467.1401411041.18130.python-list@python.org>,
>   Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>
>> On 30/05/2014 01:13, Roy Smith wrote:
>>> We've recently started using pyflakes.  The results seem to be similar
>>> to most tools of this genre.  It found a few real problems.  It
>>> generated a lot of noise about things which weren't really wrong, but
>>> were easy to fix (mostly, unused imports), and a few plain old false
>>> positives which have no easy "fix" (in the sense of, things I can change
>>> which will make pyflakes STFU).
>>>
>>> So, what's the best practice here?  How do people deal with the false
>>> positives?  Is there some way to annotate the source code to tell
>>> pyflakes to ignore something?
>>>
>>
>> I was under the impression that pyflakes was configurable.  It it isn't
>> I'd simply find another tool.  Having said that if you don't get better
>> answers here try gmane.comp.python.code-quality.
>
> I didn't know that list existed, it looks very interesting.  Thanks for
> the pointer!
>

FYI the full list of Python lists on gmane here 
http://dir.gmane.org/index.php?prefix=gmane.comp.python

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#72645

Hi,

I would recommend to use Pylint (http://www.pylint.org/) in addition
to pyflakes. Pylint is much more powerful than pyflakes, and largely
configurable.

Regards
Roland

[toc] | [prev] | [next] | [standalone]

#72679

Greetings,

> So, what's the best practice here?  How do people deal with the false 
> positives?  Is there some way to annotate the source code to tell 
> pyflakes to ignore something?
We use flake8 (pyflakes + pep8) as pre step for the tests. We fail the tests on any output from flake8.

flake8 supports ignoring certain lines by appending a comment starting with # NOQA

HTH,
--
Miki

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web