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

[Tony Meyer]

On 29/09/2005, at 3:45 AM, Fredrik Lundh wrote:

> Tony Meyer wrote:
>
>>> I thought about it, but I didn't mention it in the end because this
>>> feature ("name mangling") isn't intended as a mechanism for making
>>> things private - it's intended to prevent namespace clashes when  
>>> doing
>>> multiple inheritance.
>>
>> There is limited support for class-private identifiers.
>> [...]
>> Name mangling is intended to give classes an easy way to define
>> ``private'' instance variables and methods,
>> [...]
>> """
>
> the sentence you're quoting the first part of continues:
>
>     without having to worry about instance variables defined by  
> derived
>     classes

That elaborates on the intent, it doesn't change it.  The sentence  
clearly says that the intent is to easily define private variables,  
whereas Simon said that it the intent was not to provide a mechanism  
for making variables private.

> and the paragraph later says:
>
>     Note that the mangling rules are designed mostly to avoid  
> accidents

That's explaining why you can still access the variables if you want  
to, not saying that this feature isn't meant to be used to indicate  
that a variable is private.

> and both sentences are from the *tutorial*, which doesn't exactly
> qualify as a design document.

A tutorial should not encourage users to use a feature in the wrong  
way, though.  If leading underscore(s) were not meant to indicate  
privateness, then the tutorial should not state that - this is where  
a large proportion of users learn Python; it's nonsensical to teach  
them something that's incorrect.

> if you want more rationale, here's the
> post that led to the current design:
>
> http://groups.google.com/group/comp.lang.python/msg/e79f875059d9a2ba
>
>     "In my version, private data has it's own scope, so that name  
> clashes
>     will not occur if a private with the same name is used in a  
> subclass."
>
> see the rest of that thread for more about the history of __.

Disagreeing with someone who actually took part in the discussion may  
not be a sensible idea but...

It's pretty clear to me from that thread that using a single/double  
underscore with variables *is* intended to indicate that the variable  
is private in some fashion.  As Guido pointed out:

     '*leading* underscore has a long tradition (in the C world,
     anyway, but we don't really want to ignore that here) of meaning
     "internal use" (of some kind)'

<http://groups.google.com/group/comp.lang.python/msg/edecfde2141f642b>

The name mangling lets one use private variables without having to  
worry about name clashes, but the purpose of the leading underscore 
(s) is to indicate that the variable is private

     "private seems to be useful because it offers a form of data
     hiding that's currently absent in Python"

<http://groups.google.com/group/comp.lang.python/msg/593533b57662438f>

as many people in that thread indicated that they were doing before  
this was proposed as an addition.

The OP wanted to know how to use private (and protected) variables in  
Python.  Even the FAQ has this answer:

     'Variables with double leading underscore are "mangled" to provide
     a simple but effective way to define class private variables.
     [...]
     This doesn't guarantee privacy: an outside user can still  
deliberately
     access the "_classname__spam" attribute, and private values are  
visible
     in the object's __dict__."

<http://www.python.org/doc/faq/programming.html#i-try-to-use-spam-and- 
i-get-an-error-about-someclassname-spam>

Which is basically what I said in my reply to the OP.  If this isn't  
the intent, then there's a lot of incorrect documentation, and a lot  
of incorrect c.l.p answers to this question in the past*.

=Tony.Meyer

* Well, there are no doubt a lot of incorrect c.l.p answers to any  
question :).  But anyway...