How to formulate pylint rule to allow private variable starting with `__`

Question

Basically I have a class with a private variable:

class MyClass:
   def __init__(self, abAb):
      self.__abAb = abAb

Now, pylint complains:

Attribute name "__abAb" doesn't conform to camelCase naming style

Python does not really know about private variables, but as far as I know, it can be achieved by prepending two underscores. However, now I have the problem, that pylint complains and I did not yet find an elegant way to disable that message, whereas:

• I don't want to suppress the message for each occurrence.
• I specified regular expressions in .pylintrc to allow underscores, but then it is not possible to enforce camelCase very strictly.
• I don't want to generally disable the name checking.

Is there another way to allow such names? Something like a pylint rule "__camelCase" which I can apply to class-attributes? Or another "built-in" pythonic way?

Actually, pylint does not complain anymore after changing to snake_case naming convention:

class MyClass:
   def __init__(self, ab_ab):
      self.__ab_ab = ab_ab

That is a little bit weird, but that is all I wanted. So I will go with snake_case naming for attributes and methods.

edit: changing from camelCase to snake_case actually solves the problem with pylint.

Answer 1

Underscores, except in the case of constants, are not part of camel case, so there is not a good builtin way to accomplish this. That being said, you could add to the attr-rgx to your .pylintrc with the pattern __[a-z]+[A-Z0-9]+, but this would be mixing naming styles, so is probably not an approach you would want to take if at all avoidable.

Ideally, for python you would be using snake_case according to the official PEP8 preferred naming styles, for almost everything other than class names.

Keep in mind that naming conventions are just conventions and are mostly subjective, and your code will still work, it will just give of a bad "smell." In the case of libraries and apis, using unconventional naming conventions might make potential users less likely to integrate your code, so it might actually be detrimental to the success of your project.