Python Analyzer feedback for C0103 is confusing

When the Python Analyzer reports [C0103 invalid-name], the pattern in the feedback (‘([^\W\da-z][^\Wa-z]|__.__)$’) is basically incomprehensible.

Using backticks would help: ([^\\W\\da-z][^\\Wa-z]*|__.*__)$, but it still mostly just makes the message more confusing. Could it be removed? I don’t see much value in it being there, but maybe I’m just not familiar enough with regexes to understand it?

Also, for any enum-based approach for the Resistor Color exercises, the Analyzer generates an excessive amount of feedback (all C0103 reports):

Analyzer Feedback

Recommended

Line 8 [C0103 invalid-name] was reported by Pylint:

Class constant name “black” doesn’t conform to UPPER_CASE naming style (‘([^\W\da-z][^\Wa-z]|__.__)$’ pattern).

This code doesn’t follow general Python code style conventions. While this type of issue generally doesn’t affect the way code executes, it can hurt readability or the performance of automated tools such as documentation generators or test runners.

Instead of:

class cat:  # [invalid-name]
    def Meow(self, NUMBER_OF_MEOW):  # [invalid-name, invalid-name]
        print("Meow" * NUMBER_OF_MEOW)
        return NUMBER_OF_MEOW


Cat = cat().Meow(42)  # [invalid-name]

Try:

class Cat:
    def meow(self, number_of_meow):
        print("Meow" * number_of_meow)
        return number_of_meow


CAT = Cat().meow(42)

By default, Pylint will enforce PEP8-suggested names.

The following naming suggestions are used for Exercism exercises:

  • modules (code files): snake_case
  • constants: UPPER_CASE
  • variables: snake_case (minimum of 3 letters)
  • functions: snake_case
  • arguments: snake_case
  • attributes: snake_case
  • classes: PascalCase
  • class attributes: any (no specific format)
  • class constants: UPPER_CASE
  • class methods: snake_case
  • inline variables and loop variables: snake_case

This is only the first one, there is nine more of basically the same exact message. I can’t even post it all here because it exceeds the 10000 character limit.

@Yrahcaz7,

Thanks for the report!

UGH. For which exercise did you receive the feedback, and what does your solution look like (that triggered the feedback)?

Definitely needs massaging/fixing!

The first and second iterations here: Yrahcaz7's solution for Resistor Color in Python on Exercism

And the first iteration here: Yrahcaz7's solution for Resistor Color Duo in Python on Exercism

I suspect it would be the same for Trio and Expert as well, but I haven’t tried those yet.

1 Like

_ Class constant name “black” doesn’t conform to UPPER_CASE naming style (‘([^\W\da-z][^\Wa-z]|__. _)$’ pattern).

I would like to (gently) point out that the first part of the sentence says what the regex is reporting/looking for - that you have a lower-case Class constant (“black”), but Class constants are expected to be UPPER_CASE. But I agree that it could be clearer.


So… unfortunately, I cannot alter the rule to not report the regex unless I make an entirely new rule. I can (and have) edit(ed) the details file to make it much less verbose. I can also remove the code examples, but they don’t feel excessive when the bulleted list is omitted.

I can’t stop PyLint from calling out each “violation” individually. That means that if you fail the rule 100 times, you get 100 reports of it. This is core to the way PyLint works - you would get the same verbosity if you ran PyLint from the command line (minus the details and the code examples, which you’d have to look up).

And no - I am not going to turn off the rule. :slightly_smiling_face: It’s important for readability and other concerns. If you’d like to skip it, you can employ a pylint disable. Keep in mind you’d need one for the file, the function — or on every line where you don’t want a report of a violation.

2 Likes

It’s definitely better without the bulleted list. It is unfortunate that the regex can’t be easily removed, but I suppose it’s not that big of a problem.

Yeah, I think disabling it completely would do more harm than good.