Re: pyflakes best practices?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: pyflakes best practices?
- Original Message - > 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? > -- > https://mail.python.org/mailman/listinfo/python-list For the easy things to fix, fix them (yes, remove the unused imports). That is the best practice. pyflakes is integrated with my vim editor, it's working fine, but I used someone else script so there's possibly some tuning going on, I can't help you with that. However as someone stated before, pylint is I think a preferred solution, it's highly configurable and this is what we're using for the real deal (the code base is checked with pylint). With pylint, you can disable any checker you find annoying, you can add commented directives in the code to locally disable a checker in a block or in a line and you can write plugins to extend the pylint understanding of your code. JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: pyflakes best practices?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: pyflakes best practices?
On 30/05/2014 02:14, Roy Smith wrote: In article , Mark Lawrence 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: pyflakes best practices?
In article , Mark Lawrence 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! -- https://mail.python.org/mailman/listinfo/python-list
Re: pyflakes best practices?
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 -- https://mail.python.org/mailman/listinfo/python-list
