Question

Python classes have no concept of public/private, so we are told to not touch something that starts with an underscore unless we created it. But does this not require complete knowledge of all classes from which we inherit, directly or indirectly? Witness:

class Base(object):
    def __init__(self):
        super(Base, self).__init__()
        self._foo = 0

    def foo(self):
        return self._foo + 1

class Sub(Base):
    def __init__(self):
        super(Sub, self).__init__()
        self._foo = None

Sub().foo()

Expectedly, a TypeError is raised when None + 1 is evaluated. So I have to know that _foo exists in the base class. To get around this, __foo can be used instead, which solves the problem by mangling the name. This seems to be, if not elegant, an acceptable solution. However, what happens if Base inherits from a class (in a separate package) called Sub? Now __foo in my Sub overrides __foo in the grandparent Sub.

This implies that I have to know the entire inheritance chain, including all “private” objects each uses. The fact that Python is dynamically-typed makes this even harder, since there are no declarations to search for. The worst part, however, is probably the fact Base might inherit from object right now, but in some future release, it switches to inheriting from Sub. Clearly if I know Sub is inherited from, I can rename my class, however annoying that is. But I can’t see into the future.

Is this not a case where a true private data type would prevent a problem? How, in Python, can I be sure that I’m not accidentally stepping on somebody’s toes if those toes might spring into existence at some point in the future?

EDIT: I’ve apparently not made clear the primary question. I’m familiar with name mangling and the difference between a single and a double underscore. The question is: how do I deal with the fact that I might clash with classes whose existence I don’t know of right now? If my parent class (which is in a package I did not write) happens to start inheriting from a class with the same name as my class, even name mangling won’t help. Am I wrong in seeing this as a (corner) case that true private members would solve, but that Python has trouble with?

EDIT: As requested, the following is a full example:

File parent.py:

class Sub(object):
    def __init__(self):
        self.__foo = 12
    def foo(self):
        return self.__foo + 1
class Base(Sub):
    pass

File sub.py:

import parent
class Sub(parent.Base):
    def __init__(self):
        super(Sub, self).__init__()
        self.__foo = None
Sub().foo()

The grandparent’s foo is called, but my __foo is used.

Obviously you wouldn’t write code like this yourself, but parent could easily be provided by a third party, the details of which could change at any time.

Answer 1

This implies that I have to know the entire inheritance chain. . .

Yes, you should know the entire inheritance chain, or the docs for the object you are directly sub-classing should tell you what you need to know.

Subclassing is an advanced feature, and should be treated with care.

A good example of docs specifying what should be overridden in a subclass is the threading class:

This class represents an activity that is run in a separate thread of control. There are two ways to specify the activity: by passing a callable object to the constructor, or by overriding the run() method in a subclass. No other methods (except for the constructor) should be overridden in a subclass. In other words, only override the __init__() and run() methods of this class.