Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #36922 > unrolled thread

To make a method or attribute private

Back to article view | Back to comp.lang.python

Contents

  To make a method or attribute private  "iMath" <2281570025@qq.com> - 2013-01-17 08:34 +0800
    Re: To make a method or attribute private alex23 <wuwei23@gmail.com> - 2013-01-16 17:04 -0800
      Re: To make a method or attribute private iMath <redstone-cold@163.com> - 2013-01-20 06:52 -0800
        Re: To make a method or attribute private Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-20 15:15 +0000
    Re: To make a method or attribute private Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-17 02:38 +0000
    Re: To make a method or attribute private iMath <redstone-cold@163.com> - 2013-01-20 17:14 -0800
      Re: To make a method or attribute private Chris Angelico <rosuav@gmail.com> - 2013-01-21 12:26 +1100
      Re: To make a method or attribute private Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-21 03:27 +0000
        Re: To make a method or attribute private Chris Angelico <rosuav@gmail.com> - 2013-01-21 15:46 +1100
          Re: To make a method or attribute private alex23 <wuwei23@gmail.com> - 2013-01-20 21:44 -0800

#36922 — To make a method or attribute private

<div><div>To make a method or attribute private (inaccessible from the outside), simply start its&nbsp;</div><div>name with two underscores</div><div><br></div><div>----《Beginning Python From Novice to Professional》</div><div><br></div><div>but there is another saying goes:</div><div>Beginning a variable name with a single underscore indicates that the variable should be treated as ‘private’.</div><div><br></div><div>I test both these 2 rules ,it seems only names that start with two underscores are REAL private methods or attributes .</div><div><br></div><div>&gt;&gt;&gt; class A:</div><div>... &nbsp; &nbsp; def __init__(self):</div><div>... &nbsp; &nbsp; &nbsp; &nbsp; self.a = 'a'</div><div>... &nbsp; &nbsp; &nbsp; &nbsp; self._a = '_a'</div><div>... &nbsp; &nbsp; &nbsp; &nbsp; self.__a = '__a'</div><div>...</div><div><br></div><div><br></div><div><br></div><div>&gt;&gt;&gt; ap = A()</div><div>&gt;&gt;&gt; ap.a</div><div>'a'</div><div>&gt;&gt;&gt; ap._a</div><div>'_a'</div><div>&gt;&gt;&gt; ap.__a</div><div>Traceback (most recent call last):</div><div>&nbsp; File "&lt;stdin&gt;", line 1, in ?</div><div>AttributeError: A instance has no attribute '__a'</div><div><br></div><div>so what is your opinion about single leading underscore and private methods or attributes？</div></div>

[toc] | [next] | [standalone]

#36925

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.

[toc] | [prev] | [next] | [standalone]

#37111

在 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) ?

[toc] | [prev] | [next] | [standalone]

#37112

On Sun, 20 Jan 2013 06:52:32 -0800, iMath wrote:

[snip many dozens of lines of irrelevant text]

> what's the meaning of 'object' in
> class A(object)
> and
> class B(object) ?


Please trim your replies. We don't need to scroll past page after page of 
irrelevant text which we have already read.

"object" is the name of the base class defining common methods used by 
all new classes. In Python 2, you should always subclass object, unless 
you are subclassing something else. In Python 3, subclassing object is 
automatic, whether you write it or not.

In Python 2, if you fail to subclass object, you get an "old-style 
class", and features like property, classmethod, staticmethod, super and 
multiple inheritance may not work at all, or be buggy.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#36926

On Thu, 17 Jan 2013 08:34:22 +0800, iMath wrote:

> <div><div>To make a method or attribute private (inaccessible from the
> outside), simply start its&nbsp;</div><div>name with two
> underscores</div><div><br></div><div>----《Beginning Python From Novice
> to Professional》</div><div><br></div><div>but there is another saying
> goes:</div><div>Beginning a variable name with a single underscore
> indicates that the variable should be treated as
> ‘private’.</div><div><br></div><div> ...

Please do not send HTML emails to this newsgroup.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#37132

在 2013年1月17日星期四UTC+8上午8时34分22秒，iMath写道：
> To make a method or attribute private (inaccessible from the outside), simply start its 
> name with two underscores
> 
> 
> ----《Beginning Python From Novice to Professional》
> 
> 
> 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 .
> 
> 
> >>> class A:
> ...     def __init__(self):
> ...         self.a = 'a'
> ...         self._a = '_a'
> ...         self.__a = '__a'
> ...
> 
> 
> 
> 
> 
> 
> >>> ap = A()
> >>> ap.a
> 'a'
> >>> ap._a
> '_a'
> >>> ap.__a
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> AttributeError: A instance has no attribute '__a'
> 
> 
> so what is your opinion about single leading underscore and private methods or attributes？

so there is no REAL private variable in Python but conversion exists in it that python programmer should follow and recognize .right ?

[toc] | [prev] | [next] | [standalone]

#37133

On Mon, Jan 21, 2013 at 12:14 PM, iMath <redstone-cold@163.com> wrote:
> so there is no REAL private variable in Python but conversion exists in it that python programmer should follow and recognize .right ?

That's about it. If you think about C++ public members as the
"interface" and private/protected members as the "implementation",
then Python's convention is a leading underscore on the latter; you
can reasonably expect that non-underscore members can be trusted to be
maintained, but underscored members will quite possibly change in
subsequent versions.

Among smart people, conventions like this are all you need.

ChrisA

[toc] | [prev] | [next] | [standalone]

#37137

On Sun, 20 Jan 2013 17:14:36 -0800, iMath wrote:

[...]
> so there is no REAL private variable in Python but conversion exists in
> it that python programmer should follow and recognize .right ?

There are no "REAL private variables" in most languages. Consider the C++ 
trick "#define private public". Or pointer tricks, or using reflection in 
Java.

Yes, the convention in Python is that names starting with a single 
underscore should be considered private implementation details.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#37139

On Mon, Jan 21, 2013 at 2:27 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 20 Jan 2013 17:14:36 -0800, iMath wrote:
>
> [...]
>> so there is no REAL private variable in Python but conversion exists in
>> it that python programmer should follow and recognize .right ?
>
> There are no "REAL private variables" in most languages. Consider the C++
> trick "#define private public". Or pointer tricks, or using reflection in
> Java.

Uhh, that's like saying there are no REAL floats in C, because you can
#define float int
And pointer tricks, well, you can do anything with raw memory access.
These aren't proofs that something doesn't exist, they're proofs that
trying to enforce privacy is bound to fail - so you may as well strip
that code from your compiler/interpreter and go with the Python style.
Much easier.

I agree with your point, just not your argument. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#37153

On Jan 21, 2:46 pm, Chris Angelico <ros...@gmail.com> wrote:
> These aren't proofs that something doesn't exist, they're proofs that
> trying to enforce privacy is bound to fail

But if you can't enforce it, can you really say it exists?

Semantics, they are fun! I feel another PyWart post coming on...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web