1

Regarding the convention that a leading underscore means that an attribute is private, does this extend to access from other instances of the same class?

For example, would this be considered to break the convention?

class Man:

    def __init__(self):
        self._willy = random.randint(1,10)

    def __gt__(self, other):
        return self._willy > other._willy

In principle I don't see why it should be a problem if it is internal to your package, because it does not create any expectation that end-users can do the same, so you are still free to change the implementation later. Is this correct?

Also related to this, would access from outside the class but within the same package be considered acceptable or bad practice?

Keir
  • 53
  • 6
  • 2
    Does this answer your question? [What is the meaning of single and double underscore before an object name?](https://stackoverflow.com/questions/1301346/what-is-the-meaning-of-single-and-double-underscore-before-an-object-name) – Shivam Jha Jul 04 '20 at 06:05
  • I'm not sure if it does because it mentions that it is a hint to the programmer that the method is private, but does not really say what is meant by private. – Keir Jul 04 '20 at 06:12
  • Yes, you're breaking the convention in your example. The point of an attribute being "private" or "protected" is that the developer using the class doesn't need to reference it directly, since it's either not important outside of its class' scope (e.g. used internally for something), or there should be already a better interface to access its value (like properties). If it comes down to your example code, something's not right. – yyyyyyyan Jul 04 '20 at 06:22
  • @yyyyyyyan no, this is perfectly fine. The *whole point* of `property` is that you can do this without boilerplate getters and setters. If you want to refactor your code to control access to that attribute, you can always do `@property def _willy(self): ` – juanpa.arrivillaga Jul 04 '20 at 06:30
  • @juanpa.arrivillaga, It's not about "if you want to refactor your code", **you should**. It's not fine, it's bad practice. You shouldn't name an attribute as the convention to determine private or protected attributes if you do not want it to be treated this way. – yyyyyyyan Jul 04 '20 at 06:57
  • @yyyyyyyan I simply disagree that this violates the semantics of private attributes. Even in languages like Java, which have strict access modifiers, you are allowed to access private fields in the same class. It is perfectly reasonable to use private attributes inside the class definition. – juanpa.arrivillaga Jul 04 '20 at 07:22
  • @Keir It's simple. There are no private variables in Python, period. But there is a way to ask programmers not to mess with certain object properties because the object needs them internally, and that's using underscores for the name. Now as a grown-up person you can do as you please and ignore that, but you do it at your own risk. That's all there is to it. – Tomalak Jul 04 '20 at 07:44
  • @juanpa.arrivillaga I'm sorry, you're right, I misunderstood the initial context. Thanks! – yyyyyyyan Jul 04 '20 at 16:47

0 Answers0