Suppose I have a class with some attributes. How is it best (in the Pythonic-OOP) sense to access these attributes ? Just like obj.attr
? Or perhaps write get accessors ? What are the accepted naming styles for such things ?
Edit: Can you elaborate on the best-practices of naming attributes with a single or double leading underscore ? I see in most modules that a single underscore is used.
If this question has already been asked (and I have a hunch it has, though searching didn't bring results), please point to it - and I will close this one.
Attributes of a class can also be accessed using the following built-in methods and functions : getattr() – This function is used to access the attribute of object. hasattr() – This function is used to check if an attribute exist or not. setattr() – This function is used to set an attribute.
Accessing the attributes of a classgetattr() − A python method used to access the attribute of a class. hasattr() − A python method used to verify the presence of an attribute in a class. setattr() − A python method used to set an additional attribute in a class.
A variable stored in an instance or class is called an attribute. A function stored in an instance or class is called a method.
An instance/object attribute is a variable that belongs to one (and only one) object. Every instance of a class points to its own attributes variables. These attributes are defined within the __init__ constructor.
With regards to the single and double-leading underscores: both indicate the same concept of 'privateness'. That is to say, people will know the attribute (be it a method or a 'normal' data attribute or anything else) is not part of the public API of the object. People will know that to touch it directly is to invite disaster.
On top of that, the double-leading underscore attributes (but not the single-leading underscore attributes) are name-mangled to make accessing them by accident from subclasses or anywhere else outside the current class less likely. You can still access them, but not as trivially. For example:
>>> class ClassA: ... def __init__(self): ... self._single = "Single" ... self.__double = "Double" ... def getSingle(self): ... return self._single ... def getDouble(self): ... return self.__double ... >>> class ClassB(ClassA): ... def getSingle_B(self): ... return self._single ... def getDouble_B(self): ... return self.__double ... >>> a = ClassA() >>> b = ClassB()
You can now trivially access a._single
and b._single
and get the _single
attribute created by ClassA
:
>>> a._single, b._single ('Single', 'Single') >>> a.getSingle(), b.getSingle(), b.getSingle_B() ('Single', 'Single', 'Single')
But trying to access the __double
attribute on the a
or b
instance directly won't work:
>>> a.__double Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: ClassA instance has no attribute '__double' >>> b.__double Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: ClassB instance has no attribute '__double'
And though methods defined in ClassA
can get at it directly (when called on either instance):
>>> a.getDouble(), b.getDouble() ('Double', 'Double')
Methods defined on ClassB
can not:
>>> b.getDouble_B() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 5, in getDouble_B AttributeError: ClassB instance has no attribute '_ClassB__double'
And right in that error you get a hint about what's happening. The __double
attribute name, when accessed inside a class, is being name-mangled to include the name of the class that it is being accessed in. When ClassA
tries to access self.__double
, it actually turns -- at compiletime -- into an access of self._ClassA__double
, and likewise for ClassB
. (If a method in ClassB
were to assign to __double
, not included in the code for brevity, it would therefor not touch ClassA
's __double
but create a new attribute.) There is no other protection of this attribute, so you can still access it directly if you know the right name:
>>> a._ClassA__double, b._ClassA__double ('Double', 'Double')
So why is this a problem?
Well, it's a problem any time you want to inherit and change the behaviour of any code dealing with this attribute. You either have to reimplement everything that touches this double-underscore attribute directly, or you have to guess at the class name and mangle the name manually. The problem gets worse when this double-underscore attribute is actually a method: overriding the method or calling the method in a subclass means doing the name-mangling manually, or reimplementing all the code that calls the method to not use the double-underscore name. Not to mention accessing the attribute dynamically, with getattr()
: you will have to manually mangle there, too.
On the other hand, because the attribute is only trivially rewritten, it offers only superficial 'protection'. Any piece of code can still get at the attribute by manually mangling, although that will make their code dependant on the name of your class, and efforts on your side to refactor your code or rename your class (while still keeping the same user-visible name, a common practice in Python) would needlessly break their code. They can also 'trick' Python into doing the name-mangling for them by naming their class the same as yours: notice how there is no module name included in the mangled attribute name. And lastly, the double-underscore attribute is still visible in all attribute lists and all forms of introspection that don't take care to skip attributes starting with a (single) underscore.
So, if you use double-underscore names, use them exceedingly sparingly, as they can turn out quite inconvenient, and never use them for methods or anything else a subclass may ever want to reimplement, override or access directly. And realize that double-leading underscore name-mangling offers no real protection. In the end, using a single leading underscore wins you just as much and gives you less (potential, future) pain. Use a single leading underscore.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With