Re: [code-quality] Code-quality & PEP257

[Vladimir Keleshev]

Hi Ian,

 

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:

 

    path/file.py:14:4: PEP257 Class docstrings should have 1 blank line around them.

 

which looks pretty much the same as flake8's:

 

    coolproject/mod.py:97:1: F401 'shutil' imported but unused

 

except for dot in the end and no error/warning code. `check_source` will return a list of all errors in a string.

 

* * *

 

But still, as I was saying:

 

> Wouldn't having a

> common error format between all the tools defeat the purpose of flake8?

 

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.

 

Cheers,

Vladimir

 

 

 

17.04.2013, 14:49, "Ian Cordasco" <graffatcolmin...@gmail.com>:

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

_______________________________________________
code-quality mailing list
code-quality@python.org
http://mail.python.org/mailman/listinfo/code-quality