"you will consider most of the warnings that come from tools like pylint or pep8 or pyflakes to be a bit picky."
I use pyflakes, and out of the box it doesn't give ANY stylistic warnings, only basic "I don't think this variable exists" and common symptoms of typos like unused variables and overwriting a local var with a loop variable (I suppose you could argue that that could be a stylistic choice, but the intention is to catch errors, not correct your code style).
"The whole purpose of this project is to get people using static analysis. I think they're an excellent resource for projects and can help you find problems in your code and even learn new things." -- agreed! I'm looking forward to having a play with Prospector.
I think a better alternative is to use python mode for vim and get all the static analysis checks as you're coding. I tend to do half my development using an IDE (java/scala), but I don't really miss any of those features using this great plugin and vim.
I don't think the author's tool is in opposition to IDE/plugin based static analysis. For one thing, tools like python-mode for vim (https://github.com/klen/python-mode) call out to libraries like pylint to implement their functionality. Prospector also supports machine readable outputs that IDEs/plugins can use to determine how to display linting issues.
Even if you prefer not to use a command-line based linter, a non-GUI option is essential if you want to do linting with CI. If you run an open source Python project, you can't assume that everyone will use a linter to check for warnings before submitting a PR (and even then, can't assume their linter settings match yours)—but you can check easily lint all PRs using Travis CI or the author's company Landscape.
I should take another crack at installing python-mode for vim. Last time I did, I spent an hour at it and it ended up taking 10s to register any entered text. I didn't know how to debug stick a debugger or logger into vim plugins, so I just gave up. Sometime when I have more patience, I'll give it another try and maybe produce an actual bug report.
Anyone happen to know a good way to debug vimscript?
Why? So long as it doesn't get watered down and actually meaningfully indicates "I've made a serious effort to think about the user interaction and engineering psychology issues involved in my design.", I think its a trend that advances the industry.
They check for docstrings. From PEP 257[0]: "A docstring is a string literal that occurs as the first statement in a module, function, class, or method definition. Such a docstring becomes the __doc__ special attribute of that object."
There is not right now, although I hope to add some plugins for common IDEs and editors. You may have success using https://github.com/davidhalter/jedi-vim though - the guy who writes it is adding static analysis.
This is an awesome tool with a lot of potential and I can't wait to see it evolve. Even though all the hard work is actually done by the 3rd party checkers, THIS ties all these other tools together and makes them an order of magnitude more accessible. Well done!
I use pyflakes, and out of the box it doesn't give ANY stylistic warnings, only basic "I don't think this variable exists" and common symptoms of typos like unused variables and overwriting a local var with a loop variable (I suppose you could argue that that could be a stylistic choice, but the intention is to catch errors, not correct your code style).