To make a method or attribute private

iMath redstone-cold at 163.com
Sun Jan 20 15:52:32 CET 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