在 2013年1月17日星期四UTC+8上午9时04分00秒，alex23写道： > On Jan 17, 10:34 am, "iMath" <2281570...@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) ? -- http://mail.python.org/mailman/listinfo/python-list
