All CLA requirements met.

Question here: do we think it's important to leave the original msg_id in the message? It seems redundant to have both since they both serve the same purpose.

I would almost suggest something like this:

{msg} ({symbol})

instead of

{msg_id}:{msg} ({symbol})

Unless we think it's still necessary to have the msg_id present in the message for some reason?

While I do think the numeric codes are redundant, people who use VSCode will have built up workflows around the information that was available to them, and it might be disruptive to remove that information. Specifically, I'm thinking that people will have used the numeric codes in their local # pylint: disable=Xnnn directives, and will have a harder time maintaining stylistic consistency in future disables, if the information isn't still presented to them in the linting messages.

Additionally, I could add a new setting to allow users to customize the non-essential part of the message template. So the new template would be '{line},{column},{category},%s' % (message,) where message defaults to {msg} ({symbol}), but can be overridden in python.linting.pylintMessageFormat. The setting would have a help string like:

Controls the message template for linting results, as a new-style python format
string. The provided value will be appended to '{line},{column},{category},',
which is required by VSCode. The previous message format, using numeric message
codes, can be restored by setting this to '{msg_id}:{msg}'.  Available fields are
described at https://pylint.readthedocs.io/en/latest/user_guide/output.html.

Yes, you're right. It's a great point and I agree. It's important to respect existing workflows.

Your suggestion seems like an elegant solution to me, as it allows one to take advantage of the rich options for message control that Pylint offers.

Two things, @jcdyer . One, thanks for the PR! Most of us just got back from vacation, but we will get to reviewing your PR at some point.

Two, Travis is failing on this PR, so if you could fix that it would be great.

And thanks for providing feedback, @AWPelican , on the PR. In the end @jcdyer said what I would have as to why we need to keep the message IDs. 😄 Although I would be open to changing the format to {symbol}: {msg} ({msg_id}) to emphasize the human-friendly message.

@jcdyer @brettcannon
I believe we should retain the current format as Brett has suggested. The change you have made removes the msg_id but provides instructions in the config file. My preference is to make the changes backwards compatible.

The CI tests are failling over as the msg_id is missing.
Also, if you are going to make the format configurable, then you'll need to alter the regular expression used to parse the output. The default (named groups) regular expression is as follows (code is what maps to msg_id):

const REGEX = '(?<line>\\d+),(?<column>\\d+),(?<type>\\w+),(?<code>\\w\\d+):(?<message>.*)\\r?(\\n|$)';

I'll have time to fix this up this weekend.

This is not ready for another review yet. I'll get it cleaned up soon.

Codecov Report

Merging #495 into master will increase coverage by 0.09%.
The diff coverage is 95.23%.

@@            Coverage Diff             @@
##           master     #495      +/-   ##
==========================================
+ Coverage   56.29%   56.38%   +0.09%     
==========================================
  Files         212      212              
  Lines        9975     9993      +18     
  Branches     1754     1759       +5     
==========================================
+ Hits         5615     5635      +20     
+ Misses       4355     4353       -2     
  Partials        5        5

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d421dd3...c140167. Read the comment docs.

Some questions and concerns:

• Should I update the type of pylintMsgTemplate from string to 'legacy' | 'standard'? And should I create a named type for that?

• I don't think src/test/linters/lint.test.ts:testLinterMessages actually looks at the format of the messages. It only seems to check that messages exist when they should, and don't exist when they shouldn't. As it stands, the big lists of ILintingMessage objects in that file could be replaced by booleans: pylintHasMessages: true. But I tried to make my message objects accurate in case someone decides to flesh out those tests.

• There are some multi-line error messages (bad-whitespace, for instance), which cause the symbolic code at the end not to be displayed, because the error messages are truncated after the first line. The authors of pylint moved the error message to the end, and in parentheses, probably because the symbolic codes were harder to visually parse out than the numeric codes, but perhaps it would look reasonable to have it in parentheses before the message. Compare:

  bad-whitespace:Exactly one space required after comma
  (bad-whitespace) Exactly one space required after comma
  

  Vs. the current version with no code:

  Exactly one space required after comma
  

Another option would be to show the full multi-line message, but I'm not sure whether this is desirable, or where to enable it. I think other languages (like Rust) do it, but they have more verbose error messages in general.

@DonJayamanne any answers for the questions from @jcdyer ?

Should I update the type of pylintMsgTemplate from string to 'legacy' | 'standard'? And should I

create a named type for that?

Named type would be the way to go.

(bad-whitespace) Exactly one space required after comma

Agreed with this format, Thought I'd still prefer to see the msg_id suffixed at the end of the above message.

@brettcannon Based on the PR, the new display format would not include the msg_id in the problems window. Would that be an issue. Personally I'd prefer to see that, legacy or not, as I'd like to be able to exclude the error from the pylint config.

@brettcannon @jcdyer
Finally, shouldn't we be consistent in the way error messages are formatted for each linter. Irrespective of the linter, we should have a specific format for the messages displayed:
Either <code>:<message> or <message> (<code>) or similar.

Have a look at the following messages below:

Leaving the ID in is fine by me (some people will want that info), and I agree we should be consistent in the formatting for our own sanity in the code. 😉 I say put the user-readable name first, then the message ID since the human-readable part is what most people will use.

@DonJayamanne @brettcannon: I'm going to have some time to look at this again soon.

Personally I'd prefer to see that, legacy or not, as I'd like to be able to exclude the error from the pylint config.

You can (and should) use the textual version for excluded lints. # pylint: exclude=unused-import works just as well as # pylint: exclude=W0611, and is better documentation.

That said, the consensus seems to be to include both of them, so I'll do that.

@jcdyer Thanks for taking the time to address our comments.

@jcdyer We're hitting code freeze today, so this won't' make it in this release. Will you have time do you think to fix the merge conflicts and add back in the error number request that @DonJayamanne made for the next release?

Yes. I should have time later this week. Sorry this slipped off my radar.

@jcdyer No problem! This PR just came up in a team meeting and so I wanted to help move it forward.

This would be a great feature to get in! I currently run pylint --help-msg=W... all the time to figure out the human-readable message to disable... :P

If @jcdyer can't get an update, did you want to fork the PR and update it so we can merge it, @joshburkart ?

@brettcannon @jcdyer I'd love to! But unfortunately I think this PR looks a bit too complicated/involved for me to feel comfortable diving in, at the moment... :(

@joshburkart np

I'm going to close this issue since it isn't currently going anywhere. If anyone finds the time to fix the conflicts and address Don's comments then we can open this back up, otherwise we will try to fix it for the May release.

Ping @jcdyer?

Hi @brettcannon. I was missing the {symbol} in the output of this extension, and was looking into making a PR for fixing this.

I read through the discussion here, and have a suggestion to solve the issue without being too disruptive:

Use {msg_id}({symbol}): {msg} as the format. This is pretty much what the Parseable predefined format from pylint outputs. Messages will look like:

C0326(bad-whitespace): No space allowed around bracket

Maybe I'm suffering from Stockholm's syndrome after reading these in Jenkins output whenever my PR's contain pylint problems, but I think it is very nicely readable. It keeps the numbers, but also presents the human readable {symbol} clearly.

A detail I didn't see mentioned here is that in {msg_id}, the first letter shows what kind of problem we're dealing with; in this case a C means it is a convention.

Let me know if this could be an acceptable fix, and I will implement it (in a new PR from scratch) 😊

From the pylint tutorial:

  * (C) convention, for programming standard violation
  * (R) refactor, for bad code smell
  * (W) warning, for python specific problems
  * (E) error, for much probably bugs in the code
  * (F) fatal, if an error occurred which prevented pylint from doing further processing.

FWIW I switched to using prospector for linting Python in VSCode, which itself runs pylint and reports the human-readable pylint codes.

@qubitron do you have any input?

@jcdyer I can no longer see the numeric code for the warnings is this normal?

Yes

@jcdyer, @joshclimacell, @brettcannon
In what release do you expect these changes to take place?
I would love to see the old {msg_id} in the warning messages since our workflow at my workplace requires us to use:

# <reason for pylint-disable> pylint: disable=<numerical error representation>

@EriKWDev the PR was closed without merging, so there are no plans. If you would like the message changed then please open a new feature request.