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

[Mike Meyer]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
>> 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.

I assumed the Java model was based on the C++ model because it seems
that everything in Java is based on C++, and they share the same
vocabulary. If I'm wrong - well, that means you considered another
language already.

Sure, Java might be a big improvement. But Python isn't Java. Rather
than just throwing in something that works, do the legwork to verify
that you're going to propose a best-of-breed solution. If something
perfect is available, wouldn't you feel awful if Python got saddled
with something that wasn't perfectd?

>> 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

No, that's not the feature I was talking about. But it is *yet
another* hole you have to deal with.

> 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:

Note that you can extend an instance as well as a class, though it's a
bit more baroque to do so. But people use the ability to add a method
to a class dynamically when they want to switch between behaviors for
all objects in the class at run time. Personally, I would use a
dictionary of methods, but I don't see anything particulary wrong with
the latter approach - unless you just dislike dynamic code. Yanking a
feature because it gets misued in one place means we should probably
pre-emptively yank private to keep people from declaring things
private when they shouldn't be.

          <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.