bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib-tool.py: Fix pylint 'attribute-defined-outside-init' warnings


From: Bruno Haible
Subject: Re: gnulib-tool.py: Fix pylint 'attribute-defined-outside-init' warnings.
Date: Thu, 18 Apr 2024 00:18:02 +0200

Hi Collin,

Both patches applied.

> The reason I dislike defining instance variables outside of __init__
> is that you can run into situations like this, which I find hard to
> follow:
> 
>     var = GLImport(...)           # self.assistant does not exist.
>     var.assistant.do_something()  # This is invalid.
>     var.execute(...)              # self.assistant is now defined.
>     var.assistant.do_something()  # Now this is valid.

In this example, the property 'attribute' is used outside of the class,
that is, it is public. (In the OO world, the concept of "class" and of
"private"/"public" are tightly related, because one of the main purposes
of a class is to hide implementation details.)

Whereas GLError.message is meant to be a private property of the
__repr__ method. Since it holds state, it cannot be converted to a
local variable (like the GLImport.assistant).

Let's see what the prior knowledge summarization engine can tell us
about the distinction:
Q: In Python, what conventions exist, to distinguish a private property
   (attribute) of a class from a public property (attribute) of a class?
A: - In Python, public attributes and methods are named without leading
     underscores, indicating they're accessible from outside the class.
   - Private attributes and methods conventionally have a leading
     underscore, signaling they're for internal use and discouraging
     direct access from outside the class.
   - Additionally, Python supports name mangling with double underscores (__),
     making attributes harder to access from outside the class by modifying
     their names in the bytecode.
   - These conventions aid readability and communicate intent, but Python
     doesn't strictly enforce encapsulation.

Therefore, can you please see if after renaming message to _message the
warning in GLError persists? If yes, please report a bug to the tool
that produced this warning. The rationale why the warning is bogus is:
  - The '_message' attribute is clearly private.
  - Only one method uses it.
  - There is no other convention for state that is used by one method only.

Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]