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

[Bengt Richter]

On 2 Oct 2005 10:31:07 -0700, "El Pitonero" <pitonero at gmail.com> wrote:

>Bengt Richter wrote:
>>
>> I decided to read this thread today, and I still don't know exactly
>> what your requirements are for "private" whatevers.
>
>No name collision in subclassing. Notice that even if you use
>
>self._x = 3
>
>in a parent class, it can be overriden in a sub-sub-class accidentally.
I noticed that, and suggested a GUID-based possible approach ;-)

>
>> Or maybe, what are your real requirements?
>> ;-)
>
>No need for this type of joke.
I'm not sure what you mean, but I meant no offence, just a nudge to
refine the requirements statement, and it seems (and I hope)
Paul took it that way.
[...]
>Would any Python programmer trade the benefits of a highly dynamic
>language with an unessential feature like Java-style "private" data
>members? My guess is not.
ISTM it's not a case of either-or here ;-)
>
>---------------
>
>What do I say Java-style "private" is unessential?
>
>If your Python class/object needs a real Java-style private working
>namespace, you have to ask yourself: do the private variables REALLY
>belong to the class?
Depends on what you mean by "belong" I think ;-)

>
>In my opinion, the answer is: NO. Whenever you have Java-style private
>variables (i.e, non-temporary variables that need to persist from one
>method call to the next time the class node is accessed), those
>variables/features may be better described as another object, separate
>from your main class hierarchy. Why not move them into a foreign worker
>class/object instead, and let that foreign worker object hold those
>private names, and separate them from the main class hierarchy? (In
>Microsoft's jargon: why not use "containment" instead of
>"aggregation"?)
>
>That is, the moment you need Java-style private variables, I think you
>might as well create another class to hold those names and
>functionalities, since they do not belong to the core functionality of
>the main class hierarchy. Whatever inside the core functionality of the
>main class, should perhaps be inheritable, sharable and modifiable.
Such "another class" is what I was suggesting the automatic hidden creation of
when I said
"""
Alternatively, it might be possible to define (in the metaclass call) __getattribute__ for the class
so that it notices when method_foo or method_bar are being accessed to create bound methods, and then bind in
a proxy "self" instead that would have self.private_var on its own "self" and delegate public
attribute accesses to the normal self. Maybe this could get around byte-code-munging at the cost
of easier breakin than via inspect etc., and less run time efficiency. Just musing ...
"""
What kind of implementation were you thinking of?

>
>If you use containment instead of aggregation, the chance for name
>collision reduces dramatically. And in my opinion, it's the Pythonic
>way of dealing with the "private" problem: move things that don't
>belong to this object to some other object, and be happy again.
>
Yes, but how do you propose to implement access the "private" variables without
changing the the "spelling" too much?

Regards,
Bengt Richter