>>> class f(object):
...   def __init__(self):
...     self.__f = 1
...
 >>> a = f()
 >>> a.__f
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'f' object has no attribute '__f'
 >>> dir(a)
['__class__', '__delattr__', '__dict__', '__doc__',  
'__getattribute__', '__hash__', '__init__', '__module__', '__new__',  
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__',  
'__weakref__', '_f__f']

As you see, it's there in the dict, but it's obfuscated - but that's  
all that other languages do anyway.  Anyone that takes advantage of  
that to get hold of members like this should have a very good reason  
for doing so.

Just think of a single leading underscore as protected, and double  
leading underscores as private, and you'll be fine.  As Simon said,  
people can still access these, but the consenting adults rule applies.

There may be some. I don't know. But anyone who says "C++" is fooling
themselves:

#define private public

And your "real private and protected" objects are no longer private or
protected.

It is too easy to mistakenly read that essay as saying that Python finds a
middle ground between two binary opposites of control and chaos. That's
not the case: chaos is a privative, not an actual thing. Chaos is what
you have when you have zero control. The question should be, how much
control a language needs: control is a continuous variable, not a binary
on/off state. Less control gives more flexibility. More control reduces
opportunities.

That's a minor quibble really, the essay is grand and should be read by
all developers.

When writing Java, I write Java. When writing Python, I write Python.

Sigh. I miss him on c.l.py.