Python object attributes - methodology for access

Question

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.

Solution 1

The generally accepted way of doing things is just using simple attributes, like so

>>> class MyClass:
...     myAttribute = 0
... 
>>> c = MyClass()
>>> c.myAttribute 
0
>>> c.myAttribute = 1
>>> c.myAttribute
1

If you do find yourself needing to be able to write getters and setters, then what you want to look for is "python class properties" and Ryan Tomayko's article on Getters/Setters/Fuxors is a great place to start (albeit a little long)

Solution 2

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.

Solution 3

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.

Single underscore doesn't mean anything special to python, it is just best practice, to tell "hey you probably don't want to access this unless you know what you are doing". Double underscore however makes python mangle the name internally making it accessible only from the class where it is defined.

Double leading AND trailing underscore denotes a special function, such as __add__ which is called when using the + operator.

Read more in PEP 8, especially the "Naming Conventions" section.

Solution 4

I think most just access them directly, no need for get/set methods.

>>> class myclass:
...     x = 'hello'
...
>>>
>>> class_inst = myclass()
>>> class_inst.x
'hello'
>>> class_inst.x = 'world'
>>> class_inst.x
'world'

BTW, you can use the dir() function to see what attributes/methods are attached to your instance:

>>> dir(class_inst)
['__doc__', '__module__', 'x']

Two leading underbars, "__" are used to make a attribute or function private. For other conventions refer to PEP 08: http://www.python.org/dev/peps/pep-0008/

Solution 5

Python does not need to define accessors right from the beginning, since converting attributes into properties is quick and painless. See the following for a vivid demonstration:

Recovery from Addiction

View more solutions

Comments

[user1066101]

Are you talking about class-level attributes that belong to the class (and all objects) or instance-level attributes defined in a class? I think your question confuses class and object.

[Eli Bendersky]

I mean object attributes (instance-level), not class attributes

[Thomas Wouters]

getattr and setattr is actually the least convenient way of doing it. properties and slots are generally much more preferable.

[Eli Bendersky]

Thanks for the link - it's an excellent article very relevant to my question.

[Eli Bendersky]

Thank you for the great answer. I wish I could upvote you twice :-)

[Eli Bendersky]

I suppose that using property is even simpler

[imiric]

This is a great explanation. Thanks for the tip!

[Lie Ryan]

great answer, except that "getter and setter is evil" in python.

[Thomas Wouters]

I'm not sure what you're saying. getters and setters have their purposes; that's why we have property(). Access control just isn't one of them.