Making a method private in a python subclass

To make a method sort of private, you can name-mangle a method like so:

class Foo:
    def __blah():
        pass

class Bar(Foo):
    def callBlah():
        self.__blah() # will throw an exception

But subclasses can still find your methods through introspection if they really want to.

But Python (by deliberate design and choice) has no notion of private members.

There’s no way to truly do this in Python. Rather unpythonic, it is.

As Guido would say, we’re all consenting adults here.

Here’s a good summary of the philosophy behind everything in Python being public.

This may be a fair approximation. Lexical scoping to the “rescue”:

#!/usr/bin/env python

class Foo(object):
    def __init__(self, name):
        self.name = name
        self.bar()

    def bar(self):
        def baz():
            print "I'm private"
            print self.name

        def quux():
            baz()

        self.quux = quux


if __name__ == "__main__":
    f = Foo("f")
    f.quux()

    g = Foo("g")
    g.quux()

    f.quux()

Prints:

I'm private
f
I'm private
g
I'm private
f

I am surprised that no one has mentioned this, but prefixing the method name with a single underscore is the correct way of labelling it as “private”. It’s not really private of course, (as explained in other answers), but there you go.

def _i_am_private(self):
    """If you call me from a subclass you are a naughty person!"""

You can prefix methods and members with a single or double underscore. A single underscore implies “please don’t use me, I’m supposed to be used only by this class”, and a double underscore instructs the Python compiler to mangle the method/member name with the class name; as long as the class and its subclasses don’t have the same name, the methods/members can be considered “private”.

However, the solution to your requirements so far is to write clear documentation. If you don’t want your users to call methods in the wrong order, then say so in the documentation.

After all, even C++ privates aren’t that private. For example think the old trick:

#define private public
#include <module>

Changing an inherited method from public to private breaks inheritance. Specifically, it breaks the is-a relationship.

Imagine a Restaurant class with a open-doors public method (i.e. it’s dinnertime and we want to flip the front door sign from closed to open). Now we want a Catering class that would share many of the implementation details of Restaurant (they both need cooks, kitchens, dishes, food suppliers, and maybe even waitstaff), but not have a dining area, front doors, or the open-doors method. Inheritance from Restaurant is a mistake! It might appear that all you need to do is change the open-doors method to private so no one can use it, but then “any Catering object is-a Restaurant” is false, since part of Restaurant’s public interface is open-doors. It’s better to refactor Restaurant by adding a new base class and then both Restaurant and Catering derive from it.

Languages with a notion of protected or private inheritance support this idea of inheritance for implementation only, but Python is not one of those. (Nor is it useful in those languages, except rarely.) Usually when non-public inheritance is sought, containment (aka “has-a relationship”) is the better path, you can even make the attribute protected or private.

Python spells protected with a single leading underscore and private with double leading underscores, with the modification of the “consenting adults” philosophy mentioned in Triptych’s answer. “Dangerous” attributes and methods of your class, e.g. ones that might cause data loss, should be non-public (whether to make them protected or private is influenced by other factors), with public methods used to provide a simpler, safer interface.

“Everything must be public” proponents think the author is trying to hide a useful API from the users. This guy doesn’t want to violate an unquestionable law of Python. He wants to use some methods to define a useful API, and he wants to use other methods to organize the implementation of that API. If there’s no separation between the two it doesn’t mean the author is not an idiot. It means the author was too lazy to actually define an API.

In Python, instead of marking properties or methods as private, they may be prefixed with _ as a weak “internal use” indicator, or with __ as a slightly stronger one. In a module, names may be prefixed with _ in the same way, and you may also put a sequence of strings that constitute the modules’ public API in a variable called __all__.

A foolish consistency is the hobgoblin of little minds.

Contrary to popular fashion on this subject, there are legitimate reasons to have a distinction between public, private, and protected members, whether you work in Python or a more traditional OOP environment. Many times, it comes to be that you develop auxiliary methods for a particularly long-winded task at some level of object specialization. Needless to say, you really don’t want these methods inherited by any subclass because they make no sense in the specialized context and shouldn’t even be visible; and yet they are visible, and they diminish the utility of things like tab completion, object navigators, and other system software, because everything at all different levels of abstraction get flattened and thrown together. These programming aids are not trivial, mind you. They are only trivial if you’re a student and enjoy doing the same thing a million times just because you’re learning how.

Python historically developed in such a way that to implement the public/private distinction became increasingly difficult due to ideological inertia and compatibility concerns. That’s the plain truth. It would be a real headache for everyone to change what they’ve been doing. Consequently, we now have a million Python fans out there, all of whom have read the same one or two original articles deciding unequivocally that the public/private distinction is “unpythonic”. These people, for lack of critical thought or fairness to wide-spread, common practices, instantly use this occasion to accrete a predictable slew of appologetics — De Defensione Serpentis — which I suspect arises not from a rational selection of the via pythonis (the pythonic way) but from neglect of other languages, which they either choose not to use, are not skilled at using, or are not able to use because of work.

As someone already said, the best you can do in Python to produce an effect similar to private methods is to prepend the method name with __ (two underscores). On the other hand, the only thing this accomplishes, practically speaking, is the insertion of a transmogrified attribute name in the object’s __dict__. For instance, say you have the following class definition:

class Dog(object):
    def __bark(self):
        print 'woof'

If you run dir(Dog()), you’ll see a strange member, called _Dog__bark. Indeed, the only reason this trick exists is to circumvent the problem I described before: namely, preventing inheritance, overloading, and replacement of super methods.

Hopefully there will be some standardized implementation of private methods in the future, when people realize that tissue need not have access to the methods by which the individual cell replicates DNA, and the conscious mind need constantly figure out how to repair its tissues and internal organs.

Even among consenting adults, there are reasons why you do not want to expose methods to a derived class. The question is, can I have a hierarchy like Parent > Child, where a user can derive from either Parent or Child but not be exposed any private or protected methods. In the following example, Child explicitly overloads Parent.__private without exposing it.

class Parent(object):
    def __private(self):
        print 'Parent'

    def go(self):
        self.__private()

class Child(Parent):
    def __init__(self):
        Parent.__init__(self)
        self._Parent__private = self.__private

    def __private(self):
        print 'Child'

class MyClass(object): 
    def _prtectedfunc(self):
        pass # with one undersocre

    def __privatefunc(self):
        pass # with two undersocre

http://linuxwell.com/2011/07/21/private-protected-and-public-in-python/

There are many good answers in this thread but here is somewhat opinionated answer from practical point of view:

You do need to hide (aka document) low level variables and methods from public APIs. So always attach _ or __ to these members. The bigger question: Should it be _ or __? The purist OOP perspective is to always attach __ to private members and _ to “protected” methods (i.e. accessible, overridable from derived class). The __ makes sure that derived class cannot override it. On the other hand it also makes it difficult to use things like setattr, testability and readability.

My personal view (as well as Google’s style guide) is to avoid __ as much as possible and use _ for private members.

But what about protected members? How do we tell our library users what do they must/should override? Here I prefer not to use underscore for protected members and instead rely on docstring comments and optionally @abstractmethod in base class. One advantage here is that protected members then does not get dropped from various documentation generators.

There are many good answers in this thread but here is somewhat opinionated answer from practical point of view:

You do need to avoid crud of private members from public APIs, intellisense, docs, import * etc. So always attach _ or __ to these members.

The big question: Should it be _ or __? The purist OOP perspective is to always attach __ to private members and _ for protected methods. The __ does name mangling and makes it hard to use things like setattrib, test frameworks and reduces readability. So my personal view is to avoid __ as much as possible and use _ for private members.

But what about protected members which we want derived class to use but not as public API. My preference here is to use no underscore at all. This allows these members to get in public docs. We then rely on docstring to tell user that these are protected members like this:

class Class1:
  def _private1():
    pass

  def protected1():
    """(for derived classes) Does XYZ."""
    pass

  def public1()
    pass