On Wed, Apr 17, 2013 at 8:49 AM, Ian Cordasco <graffatcolmin...@gmail.com> wrote: > On Mon, Apr 15, 2013 at 2:59 PM, Vladimir Keleshev > <vladi...@keleshev.com> wrote: >> Hi Ian, >> >> I'm actually on the mailing list as well (since maybe 2 weeks ago). You >> might remember my email about proposing a common format for error messages. >> I think it's a great idea to coordinate development of our static-analysis >> tools. Adding pep257 to flake8 might be a good idea. Shall we call it >> fla257ke8? :o) >> >> But I'm not sure I understand the purpose of flake8. Wouldn't having a >> common error format between all the tools defeat the purpose of flake8? Then >> a dummy runner would suffice. Imagine a world where all static analysis >> tools have a common output format and same command-line interface and error >> conventions. >> >> Cheers, >> Vladimir > > Hey Vladimir, > > I'm awful with names, so I apologize for not putting your post there > together with the fact you work on PEP257. > > flake8 (as soon as we update to pyflakes 0.7 which was just announced) > will have a consistent error format. (Prior to 2.0, our vendored copy > of pyflakes provided column reporting which was just introduced in > pyflakes 0.7 and was missing in every official version prior to it.) > As for the purpose of flake8, it was created to run pep8 and pyflakes > and optionally check the McCabe complexity score. It is already > extensible to check naming conventions via pep8, so extending it (most > likely through an add-on) to check doc-strings would be a logical > step. > > I'm not readily familiar with pep257's error reporting, but in > skimming over the code I noticed the Error class. I'm sure if we had > to, we could monkey patch your tool (as we already monkey patch > pyflakes), to standardize the output for flake8 users. Due to the fact > we can do that (and already do), I'm not sure attempting to make a > standard way to report errors, warnings, etc. is an immediate > priority. It's certainly something to consider, but we will encounter > the issue where tools are old enough to have other tools written to > parse their output. They could add options for different styles of > reporting, but if they're anything like pep8, they already have those > options which makes this a non-issue. > > Anyway, I look forward to working with you on integrating pep257 into > flake8 and I hope to hear more from you. > > Cheers, > Ian
And after re-reading a couple Flake8 issues, I re-discovered this project: https://github.com/fedora-static-analysis/firehose It was suggested to us by the author itself and you'll probably find it very interesting Vladimir. :) I'm looking into it myself _______________________________________________ code-quality mailing list code-quality@python.org http://mail.python.org/mailman/listinfo/code-quality
