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