Error codes (Was: Pyflakes forked to Frosted)

On Sun, Jan 19, 2014 at 11:12 AM, Kay Hayen <kay.hayen@gmail.com> wrote:
Hello,
this was interesting to me:
Error numbers in tools such as pep8 and pyflakes (although flake8 adds them to pyflakes) are usually not made to be entirely successive. For the most part, there are groupings of errors. The best explanation of this is pep8's documentation: http://pep8.readthedocs.org/en/latest/intro.html#error-codes
Anything starting with E1 is related to indentation, anything starting with E2 is related to whitespace. These are conceptually classes of errors. PyLint also follows this convention if I remember correctly and you would do well to do the same. The error codes that Flake8 adds to PyFlakes follow that convention as well.
So for my compiler Nuitka, there are very few warnings so far, mostly because it is very limited in its tracing abilities, but I am expanding this now, and so far I was kind of clueless on how to properly format error and warning messages.
It probably will a while, before I find the need to expand it, but it would be good to have a common ground, reusable data. For PyLint, these texts seem spread out in the variables files.
You would do best to research (and possibly revive) past conversations on this list about a standardization of error messages. I believe the standard that Flake8 uses is also pep8's format (which is similar to PyLint). pep257 also has a rewrite branch to use that format. Trying to create a standard about something so subjective is difficult and it becomes more difficult when tools like pep8 support providing your own formatter.
Is there an easy way to access the PyLint warning/error message texts.
I would hope so, but I do not personally know.
Would you be OK with me to grep these out of PyLint or Wiki, and use them under ASF2 in my project as well. I would of course prefer, for these to exist a place that makes reuse easier.
I cannot grant you permission to do this because I am not associated with the project. For others reading the list, the ASF2 refers to https://www.apache.org/licenses/LICENSE-2.0, also known as the Apache License 2.0. I'm also a bit fuzzy on the compatibility of the LGPL2.1 with Apache 2.0. I'm also not entirely certain how PyLint's error codes would benefit your project.
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. 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. Cheers, Ian

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
participants (2)
-
Ian Cordasco
-
Kay Hayen