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...
--
http://mail.python.org/mailman/listinfo/python-list
