Making a method private in a python subclass

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.

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.

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>