Will python never intend to support private, protected and public?

[Paul Rubin]

Mike Meyer <mwm at mired.org> writes:
> > If you have a java class instance with a private member that's (say) a
> > network socket to a special port, access to the port is controlled
> > entirely by that class.
> 
> Are you sure? My understanding was that Java's introspection mechanism
> could be used to access private variables.

Right, I should have been more specific, if I understand correctly,
there are some JVM settings that turn that on and off (I'm not any
kind of expert on this).  For sandbox applets, it's turned off, for
example.  This came up in a huge discussion thread on sci.crypt a few
months ago.  Apparently the default is for it to be turned on, to the
surprise and disappointment of some:

  http://groups.google.com/group/sci.crypt/msg/23edaf95e9978a8d

> A couple of other things to think about:
> Are you sure you want to use the C++ model for privilege separation?

I'm not sure what you mean by the C++ model.  If you mean the Java
model, as I keep saying, applet sandbox security relies on it, so it
may not be perfect but it's not THAT bad.  Using it routinely in
normal applications would be a big improvement over what we do now.
High-security applications (financial, military, etc.) would still
need special measures.

> C++'s design doesn't exactly inspire confidence in me. 

Me neither, "C++ is to C as lung cancer is to lung".  

> Finally, another hole to fix/convention to follow to make this work
> properly in Python. This one is particularly pernicious, as it allows
> code that doesn't reference your class at all to violate the private
> variables. Anyone can dynamically add methods to an instance, the
> class it belongs to, or to a superclass of that class. 

Yes, Python isn't even type-safe any more:

    class A(object): pass
    class B(object): pass
    a = A()
    print type(a)
    a.__class__ = B
    print type(a)    # oops

IMHO that "feature" you describe is quite inessential in Python.  The
correct way to override or extend the operations on a class is to
subclass it.  I can't think of a single place where I've seen Python
code legitimately go changing operations by jamming stuff into the
class object.  I'd consider the stdlib's socket.py to be illegitimate
and it cost me a couple of hours of debugging one night:

 http://groups.google.com/group/comp.lang.python/msg/c9849013e37c995b

and even that is only messing with specific instances, not classes.
Make sure to have a barf bag handy if you look at the socket.py code.
I really should open a sf bug about it.