Attribute naming convention when deriving from class that may change in the future

Question

My question is quite general, but for clarity I'd like to give an example that is as concrete as possible: I was lately writing a class, which was derived from a matplotlib artist . A minimal working example would be the following:

from matplotlib import text

class TextChild(text.Text):
    def __init__(self):
        self._rotation = self.get_rotation()

The idea behind using an underscore self._rotation was to show the potential user not to access that attribute directly (ie to label it private). This turned out to be a bad idea, because text.Text also has an attribute called _rotation and I got very surprising results.

There are, of course, ways to deal with this.

• One is to use a different attribute name, say, self._rotation2 , but the base class may be subject to change in the future, possibly introducing new attributes and with a bit of bad luck names might again match, which would break the derived class.
• Another solution would be to use name mangling, ie self.__rotation (the solution I chose). From what I understood, however, name mangling should be used as sparsely as possible and if I have many private attributes there will be a lot of double underscores in the code.

So here is the question: Is there a preferred way of naming private class attributes when deriving from a class out of my own control that may change in the future?

Answer 1

Is there a preferred way of naming private class attributes when deriving from a class out of my own control that may change in the future?

It's really difficult to tell how you should choose the name of identifiers in your code, this is open to you. Generally speaking, it's your job as a programmer to avoid name collisions, some advanced IDEs can aide in this process.

For you question I believe using name mangling will definitely avoid name collisions somehow, this won't litter your code with underscores as you might think given that you use this feature wisely. If you're using a lot of redundant names, it's better to choose unique names instead. It's generally acceptable to use __name for attributes that you would like to ensure that they belong to their classes and please remember private in Python isn't really private, it's really pseudo-private. You'll still be able to access those attributes.

Here's one trick that you can use to avoid name collisions:

>>> "name" in dir(Foo)
True

So if name is already there in the namespace of class Foo , you would know from this single line and to get a list of all the attributes of class Foo just call dir with Foo as its argument: dir(Foo) .

Mainly this is a design issue, but if I were in your position I'd opt to check with dir to ensure the uniqueness of my names to avoid overriding other names unintentionally. For example, if you read the codes of Python standard library, in many places the use of _name naming convention to denote this name should not be directly accessed from outside the class is pretty obvious.