Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: To make a method or attribute private

Reply
Thread Tools

Re: To make a method or attribute private

 
 
alex23
Guest
Posts: n/a
 
      01-17-2013
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.
 
Reply With Quote
 
 
 
 
iMath
Guest
Posts: n/a
 
      01-20-2013
在 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) ?
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      01-20-2013
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: To make a method or attribute private iMath Python 4 01-21-2013 05:44 AM
To make a method or attribute private iMath Python 5 01-21-2013 02:45 AM
Re: To make a method or attribute private Lie Ryan Python 0 01-18-2013 07:46 AM
Re: To make a method or attribute private Steven D'Aprano Python 0 01-17-2013 02:38 AM
How can I make XMLHttpRequsts onreadystatechange a private method? Daz Javascript 3 05-11-2007 09:48 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57