With regards to the single and double-leading underscores: both indicate the same concept of ‘privateness’. That is to say, people will know the attribute (be it a method or a ‘normal’ data attribute or anything else) is not part of the public API of the object. People will know that to touch it directly is to invite disaster.
On top of that, the double-leading underscore attributes (but not the single-leading underscore attributes) are name-mangled to make accessing them by accident from subclasses or anywhere else outside the current class less likely. You can still access them, but not as trivially. For example:
>>> class ClassA:
... def __init__(self):
... self._single = "Single"
... self.__double = "Double"
... def getSingle(self):
... return self._single
... def getDouble(self):
... return self.__double
...
>>> class ClassB(ClassA):
... def getSingle_B(self):
... return self._single
... def getDouble_B(self):
... return self.__double
...
>>> a = ClassA()
>>> b = ClassB()
You can now trivially access a._single and b._single and get the _single attribute created by ClassA:
>>> a._single, b._single
('Single', 'Single')
>>> a.getSingle(), b.getSingle(), b.getSingle_B()
('Single', 'Single', 'Single')
But trying to access the __double attribute on the a or b instance directly won’t work:
>>> a.__double
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: ClassA instance has no attribute '__double'
>>> b.__double
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: ClassB instance has no attribute '__double'
And though methods defined in ClassA can get at it directly (when called on either instance):
>>> a.getDouble(), b.getDouble()
('Double', 'Double')
Methods defined on ClassB can not:
>>> b.getDouble_B()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 5, in getDouble_B
AttributeError: ClassB instance has no attribute '_ClassB__double'
And right in that error you get a hint about what’s happening. The __double attribute name, when accessed inside a class, is being name-mangled to include the name of the class that it is being accessed in. When ClassA tries to access self.__double, it actually turns — at compiletime — into an access of self._ClassA__double, and likewise for ClassB. (If a method in ClassB were to assign to __double, not included in the code for brevity, it would therefor not touch ClassA‘s __double but create a new attribute.) There is no other protection of this attribute, so you can still access it directly if you know the right name:
>>> a._ClassA__double, b._ClassA__double
('Double', 'Double')
So why is this a problem?
Well, it’s a problem any time you want to inherit and change the behaviour of any code dealing with this attribute. You either have to reimplement everything that touches this double-underscore attribute directly, or you have to guess at the class name and mangle the name manually. The problem gets worse when this double-underscore attribute is actually a method: overriding the method or calling the method in a subclass means doing the name-mangling manually, or reimplementing all the code that calls the method to not use the double-underscore name. Not to mention accessing the attribute dynamically, with getattr(): you will have to manually mangle there, too.
On the other hand, because the attribute is only trivially rewritten, it offers only superficial ‘protection’. Any piece of code can still get at the attribute by manually mangling, although that will make their code dependant on the name of your class, and efforts on your side to refactor your code or rename your class (while still keeping the same user-visible name, a common practice in Python) would needlessly break their code. They can also ‘trick’ Python into doing the name-mangling for them by naming their class the same as yours: notice how there is no module name included in the mangled attribute name. And lastly, the double-underscore attribute is still visible in all attribute lists and all forms of introspection that don’t take care to skip attributes starting with a (single) underscore.
So, if you use double-underscore names, use them exceedingly sparingly, as they can turn out quite inconvenient, and never use them for methods or anything else a subclass may ever want to reimplement, override or access directly. And realize that double-leading underscore name-mangling offers no real protection. In the end, using a single leading underscore wins you just as much and gives you less (potential, future) pain. Use a single leading underscore.