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

[Bengt Richter]

On 03 Oct 2005 14:45:43 -0700, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:

>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.
But a class definition is just a syntactic sugar way to associate functions
with certain automatic method-binding operations for its instances, invoked
by other syntactic sugar. But you can do it without modifying the class itself.
E.g.,

 >>> add5 = (lambda self, x: self+x).__get__(5, type(5))
 >>> add5
 <bound method int.<lambda> of 5>
 >>> add5(10)
 15

I can't stuff the method on type(5) since it's built in,

 >>> type(5).add5 = (lambda self, x: self+x).__get__(5, type(5))
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
 TypeError: can't set attributes of built-in/extension type 'int'

but that doesn't stop forming a bound method ;-)

for a better name than <lambda> you can always fix it up ;-)

 >>> add5.im_func.func_name = 'add5'
 >>> add5
 <bound method int.add5 of 5>

Regards,
Bengt Richter