<div dir="ltr"><div>Regarding the output, the Flake8 tool returns <row> and <col>.<br>And IIUC the pylint tool returns only <row>.<br><br>None of these tools is able to detect and return <end-line> and <end-char>.<br>

<br>-- <br></div>Florent<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/2 Florent <span dir="ltr"><<a href="mailto:florent.xicluna@gmail.com" target="_blank">florent.xicluna@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hello Vladimir,<br><br></div><div>I would like to give some information about what is already available regarding some tools.<br>

<br></div>First, you might know that there's some effort to merge the output of Pyflakes and Pep8 tools within Flake8.<br>
</div>Today Flake8 supports all the options of Pep8 (and can be extended for plugins).<br>For example, a useful feature is to mimic the "pylint" format with `flake8 --format pylint`.<br></div></div><br></div><div>


There's also a feature request which asks for JSON output for flake8.<br></div><div><a href="https://bitbucket.org/tarek/flake8/issue/99" target="_blank">https://bitbucket.org/tarek/flake8/issue/99</a><br><br><div><div>

<div>This is the current state for the Flake8 tool (and its libraries).<br>
</div><div>I don't know much about pylint and other tools.<span class="HOEnZb"><font color="#888888"><br><br>-- <br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Florent<br></div><div><br><br></div>

</font></span></div></div></div></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br><br></font></span><div class="gmail_quote"><span class="HOEnZb"><font color="#888888">2013/4/2 Vladimir Keleshev <span dir="ltr"><<a href="mailto:vladimir@keleshev.com" target="_blank">vladimir@keleshev.com</a>></span><br>


</font></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div>Hi everyone,</div><div> </div><div>I'm very excited about the new mailing list. I wanted to share an old idea of mine, which is probably unoriginal, but can kick-start a discussion.</div>


<div> </div><div>What about all of our static analysis tools adopt a *common* machine-friendly error format, so that we could write editor plugins once, and then all of our tools would work interchangeably, and new tools could be adopted without need to update editor plugins.</div>


<div> </div><div>The proposed format could be triggered by a decided-upon option, e.g. --machine-friendly, with this usage-pattern:</div><div> </div><div>    usage: <tool> --machine-friendly <file>...</div><div>


 </div><div>The proposed format would consist of the following lines:</div><div> </div><div>    </absolute/path/to/file>:<start-line>:<start-char>...<end-line>:<end-char>: <error-message></div>


<div> </div><div>For example:</div><div> </div><div>    /home/username/git/project/project.py:65:4...65:7: Infinite `for` loop</div><div>    /home/username/git/project/another.py:1:1...1:5: `re` imported, but not used</div>


<div> </div><div>This is very similar to what most static analysis tools (and compilers) do anyway. But it also adds <start-char> and <end-char> which allow for precise error-highlighting in the editor.</div>

<div>
 </div><div>What do you think?</div><div> </div><div>Best,</div><div>Vladimir</div><br></div></div><div class="im">_______________________________________________<br>
code-quality mailing list<br>
<a href="mailto:code-quality@python.org" target="_blank">code-quality@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/code-quality" target="_blank">http://mail.python.org/mailman/listinfo/code-quality</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>