A lot of people erroneously use double underscores to simulate “private” members, because double underscores invokes code mangling and makes those members harder to reference outside the class. However, it does not actually make them inaccessible.

Most of the time, it mainly adds a road bump to unit testing.

Really the double underscore mangling mechanism is to hide those members from subclasses that you don’t want clobbering the values inadvertently. Name mangling isn’t intended to hide the member from other programmers; the mangling scheme is simple, and referencing the variables anyway is easy.

Single underscore is the common convention for internal members. That’s saying, we’re all adults here, and although you can see it, this variable is intended for internal use. If you reference it, there’s no guarantee it will still be there in future versions.

The Pep8 doc talks about that, and says use of the double underscores for variables and functions should really be rare.

The feature is specifically meant for preventing accidental clashes between a parent class member and subclasses.

The name is mangled by prepending it with the class name; the atribute __foo on a class Bar becomes _Bar__foo, and can still be accessed as such from outside.

This makes such attributes obscured at best, not private. The only real use-case for such attributes is for member attributes that are tied to the specific implementation of a parent class method that a subclass might accidentally overwrite with their own version.

Adding to Rob Y’s answer: many think that using the double underscore prevents the method from getting overridden, but that is not true:

class Me(object):
    def override_me(self):
        print "Me: I should NOT be called"

    def __dont_override_me(self):
        print "Me: I SHOULD be called"

class OverrideMe(Me):
    def override_me(self):
        print "OverrideMe: I SHOULD be called"

    def __dont_override_me(self):
        print "OverrideMe: I should NOT be called"


me = Me()
override = OverrideMe()

me._Me__dont_override_me()
override.override_me()
override._OverrideMe__dont_override_me()

Output:

Me: I SHOULD be called
OverrideMe: I SHOULD be called
OverrideMe: I should NOT be called

It depends on how you access it, and has nothing to do with preventing overriding.

However, name mangling will prevent me.__dont_override_me() to be called, as it will throw an attribute error:

me.__dont_override_me()

Output:

Traceback (most recent call last):
  File "/private/tmp/stackoverflow.py", line 23, in <module>
    me.__dont_override_me()
AttributeError: 'Me' object has no attribute '__dont_override_me'

The comment made by Alex Punnen is incorrect, but unluckily I don’t have the reputation point to add comment there. What he tries to do is to abuse the “grown man” assumption of Python to directly call the mangled methods, which is not what is expected to be done anyway. In any case, if you write a new __dont_override_me method in a subclass, you don’t get overriding. You get overloading instead: an unrelated method with the same name. The key difference is that the “old” code, i.e., code in the base class Me, will not (normally, unless you use the mangled name directly) call that new method. In his example:

class Me(object):
    def override_me(self):
        print "Me: I should NOT be called"

    def not_overriden(self):
        self.__dont_override_me()

    def __dont_override_me(self):
        print "Me: I SHOULD be called"

class OverrideMe(Me):
    def override_me(self):
        print "OverrideMe: I SHOULD be called"

    def __dont_override_me(self):
        print "OverrideMe: I should NOT be called"

me = Me()
override = OverrideMe()

me.override_me()
me.not_overriden()
override.override_me()
override.not_overriden()

This runs with the following result:

Me: I should NOT be called
Me: I SHOULD be called
OverrideMe: I SHOULD be called
Me: I SHOULD be called