Hello Ian,

> Basically, I am saying, why isn't this some kind of standard. And can we
> make it
> one.

Standardizing anything is difficult. People rarely agree on anything.
One way to achieve your standard, however, may be to write a package
(ideally permissively licensed like Nuitka) that provides formatters
for the more popular options, i.e., pep8 and pyflakes. Then simply
encourage those writing similar tools to use that to reduce code
duplication and possible errors. If your module achieves enough
popularity, it would then become a de facto standard rather than a
standard designed by committee.

I was not suggesting it any other way. Of course in code.

But thinking of it, that subjective thing bears fruits. But for mere statements
of facts, I wouldn't worry as much. Of course, already when it makes
suggestions, then likely it is going to be deviating. I for one wouldn't
worry even people use "map" in their code or list contractions. Such
hints could be kept separate from the statement of fact.

I would of course be willing to make the result freely licensed, but that
would require allowance from PyLint.
 
Further, you seem to be conflating ideas:

- Message/warning formatting
- Error code design

The former deals with how the message is printed, while the latter is
far more semantic in how error codes are assigned. The latter will be
far harder to codify than even the former. Again a module to help with
this may work but I would guess that people will be less inclined to
use it than a module which formats the messages for them.

The formatting doesn't matter as much, PyLint now offers an option to
control the output and the colorizing for interactive terminals isn't really
all that hard. It's now even easy to use with Emacs compilation mode.
 
For the design, yes, that is where I would be the most benefit for my
project, because PyLint messages, that is what people already know
and recognize, and where other people will continue to put more and
more thought into.

Using the same message catalog will also make it easier to compare
the tools.

That said, without such a standard, I would love to follow PyLint in what
it does. There isn't to the user not that much benefit to it doing the same
outputs, they will still use PyLint, but there even more clearly is no benefit
to using different wordings for the same facts.

Plus, it would then be natural to use the same comments to enabled and
disable messages. The same options to control warnings, and the same
configuration file formats. Lots of benefits to me that will turn out as
benefits to my users as well.

Basically I want to do as little thinking, documenting, heck, I could even
use the tests of PyLint (hoping they exist).

But these benefits can not only apply to me. Shared messages and test
cases must be good for everybody doing this kind of stuff.

Yours,
Kay