<div>Hi Ian,</div><div>š</div><div>I'm ready to assist you with integrating pep257 into flake8. Do you plan to vendorize it or make it a dependency? `Error` is the right class to look for. `__str__` formats the error. The default format looks like:</div><div>š</div><div>š š path/file.py:14:4: PEP257 Class docstrings should have 1 blank line around them.</div><div>š</div><div>which looks pretty much the same as flake8's:</div><div>š</div><div>š ššcoolproject/mod.py:97:1: F401 'shutil' imported but unused</div><div>š</div><div>except for dot in the end and no error/warning code. `check_source` will return a list of all errors in a string.</div><div>š</div><div>* * *</div><div>š</div><div>But still, as I was saying:</div><div>š</div><div>> Wouldn't having a</div><div>> common error format between all the tools defeat the purpose of flake8?</div><div>š</div><div>About Firehose: I find itšover-engineered. It is radically different from any current error formats. I think that only something simple can succeed when it comes to standards that cannot be enforced.</div><div>š</div><div>Cheers,</div><div>Vladimir</div><div>š</div><div>š</div><div>š</div><div>17.04.2013, 14:49, "Ian Cordasco" <graffatcolmingov@gmail.com>:</div><blockquote type="cite"><p>On Mon, Apr 15, 2013 at 2:59 PM, Vladimir Keleshev<br /><<a href="mailto:vladimir@keleshev.com">vladimir@keleshev.com</a>> wrote:</p><blockquote>šHi Ian,<br /><br />šI'm actually on the mailing list as well (since maybe 2 weeks ago). You<br />šmight remember my email about proposing a common format for error messages.<br />šI think it's a great idea to coordinate development of our static-analysis<br />štools. Adding pep257 to flake8 might be a good idea. Shall we call it<br />šfla257ke8? :o)<br /><br />šBut I'm not sure I understand the purpose of flake8. Wouldn't having a<br />šcommon error format between all the tools defeat the purpose of flake8? Then<br />ša dummy runner would suffice. Imagine a world where all static analysis<br />štools have a common output format and same command-line interface and error<br />šconventions.<br /><br />šCheers,<br />šVladimir</blockquote><p>Hey Vladimir,<br /><br />I'm awful with names, so I apologize for not putting your post there<br />together with the fact you work on PEP257.<br /><br />flake8 (as soon as we update to pyflakes 0.7 which was just announced)<br />will have a consistent error format. (Prior to 2.0, our vendored copy<br />of pyflakes provided column reporting which was just introduced in<br />pyflakes 0.7 and was missing in every official version prior to it.)<br />As for the purpose of flake8, it was created to run pep8 and pyflakes<br />and optionally check the McCabe complexity score. It is already<br />extensible to check naming conventions via pep8, so extending it (most<br />likely through an add-on) to check doc-strings would be a logical<br />step.<br /><br />I'm not readily familiar with pep257's error reporting, but in<br />skimming over the code I noticed the Error class. I'm sure if we had<br />to, we could monkey patch your tool (as we already monkey patch<br />pyflakes), to standardize the output for flake8 users. Due to the fact<br />we can do that (and already do), I'm not sure attempting to make a<br />standard way to report errors, warnings, etc. is an immediate<br />priority. It's certainly something to consider, but we will encounter<br />the issue where tools are old enough to have other tools written to<br />parse their output. They could add options for different styles of<br />reporting, but if they're anything like pep8, they already have those<br />options which makes this a non-issue.<br /><br />Anyway, I look forward to working with you on integrating pep257 into<br />flake8 and I hope to hear more from you.<br /><br />Cheers,<br />Ian</p></blockquote>