To make a method or attribute private
iMath
redstone-cold at 163.com
Sun Jan 20 09:52:32 EST 2013
在 2013年1月17日星期四UTC+8上午9时04分00秒,alex23写道:
> On Jan 17, 10:34 am, "iMath" <2281570... at qq.com> wrote:
>
> > To make a method or attribute private (inaccessible from the outside), simply start its
>
> > name with two underscores
>
> >
>
> > but there is another saying goes:
>
> > Beginning a variable name with a single underscore indicates that the variable should be treated as ‘private’.
>
> > I test both these 2 rules ,it seems only names that start with two underscores are REAL private methods or attributes .
>
> > so what is your opinion about single leading underscore and private methods or attributes?
>
>
>
> The key word in the second quote is "indicates". Placing a single
>
> underscore before an attribute name does nothing but _show_ other
>
> programmers that you consider this to be part of the implementation
>
> rather than the interface, and that you make no guarantees of its
>
> continued existence over time.
>
>
>
> More importantly, however: there is no real concept of "private"
>
> attributes in Python. Try this at the command prompt:
>
>
>
> >>> ap._A__a
>
> '__a'
>
>
>
> It's still readable, and it's still writable too. The double-
>
> underscore naming is referred to as "name mangling" and while it's
>
> often passed off as the way to make private methods in Python (the
>
> tutorial even states this), what it is really intended for is to
>
> ensure that multiple inheritance works correctly:
>
>
>
> >>> class A(object):
>
> ... foo = 'A'
>
> ... def get_A_foo(self):
>
> ... return self.foo
>
> ...
>
> >>> class B(object):
>
> ... foo = 'B'
>
> ... def get_B_foo(self):
>
> ... return self.foo
>
> ...
>
> >>> class C(A, B):
>
> ... def __init__(self):
>
> ... super(C, self).__init__()
>
> ...
>
> >>> c = C()
>
> >>> c.get_A_foo()
>
> 'A'
>
> >>> c.get_B_foo()
>
> 'A'
>
>
>
> Here, we haven't mangled the attribute 'foo' on either A or B, so on
>
> the instance of C, which inherits from both, the inherited methods are
>
> referring to the same attribute, which is A's in this case due to the
>
> method resolution order. By re-naming 'foo' on both A and B to
>
> '__foo', each can then refer to their _own_ attribute, and also allow
>
> for C to have its own 'foo' attribute which doesn't conflict with
>
> either of them:
>
>
>
> >>> class A(object):
>
> ... __foo = 'A'
>
> ... def get_A_foo(self):
>
> ... return self.__foo
>
> ...
>
> >>> class B(object):
>
> ... __foo = 'B'
>
> ... def get_B_foo(self):
>
> ... return self.__foo
>
> ...
>
> >>> class C(A, B):
>
> ... foo = 'C'
>
> ... def __init__(self):
>
> ... super(C, self).__init__()
>
> ...
>
> >>> c = C()
>
> >>> c.get_A_foo()
>
> 'A'
>
> >>> c.get_B_foo()
>
> 'B'
>
> >>> c.foo
>
> 'C'
>
>
>
> There is no way to make an externally private attribute. This is
>
> generally considered a good thing by most Python developers: if I
>
> _need_ to access your class's implementation, I can do so, but the
>
> name mangling forces me to be aware that this is something you don't
>
> recommend doing. You'll often hear the term "consenting adults" used
>
> to refer to this, meaning we can all decide for ourselves if we're
>
> willing to risk using an implementation detail.
what's the meaning of 'object' in
class A(object)
and
class B(object) ?
More information about the Python-list
mailing list