Which way to say 'private'?

[Daniel Klein]

There are 2 ways to indicate private members of classes, by prepending
1 or 2 underscore characters, the latter causing name mangling. My
question is: When would I use which kind to indicate privacy?

Thanks,
Daniel Klein
Member of the Dead Parrot Society

[Alex Martelli]

Re: Which way to say 'private'?

Daniel Klein wrote:
[color=blue]
> There are 2 ways to indicate private members of classes, by prepending
> 1 or 2 underscore characters, the latter causing name mangling. My
> question is: When would I use which kind to indicate privacy?[/color]

You would normally use a single underscore, which is an advisory
indication of privacy. You would use two underscores, with the
mangling they produce, when you need to ensure against any risk
of accidental conflict with other existing names in the same space.

For example, if your class injects for its own purposes attributes
in other unrelated objects, it might be quite prudent to use the
double-underscore syntax for the names of those 'alien' attributes,
otherwise name clashes are far too likely to occur.


Alex

[Sean Ross]

Re: Which way to say 'private'?

"Daniel Klein" <danielk@aracne t.com> wrote in message
news:14f9kv4fvu f67k6j12lpgt6vk 9dcpefchm@4ax.c om...[color=blue]
> There are 2 ways to indicate private members of classes, by prepending
> 1 or 2 underscore characters, the latter causing name mangling. My
> question is: When would I use which kind to indicate privacy?[/color]

Hi.
The single underscore (self._attribut e) is the convention when you wish to
indicate privacy. Where by "indicate" I mean that you wish to convey to
readers of the code that they should not access this attribute directly.
They can, but you are telling them that it's not the best practice for your
API. The double underscore (self.__attribu te) mangles the name (as you've
mentioned), so it adds an extra disincentive to using that attribute
directly (at the very least, using instance._Class Name__attribute makes for
unattractive code). So, the latter method is used when you would really,
really prefer that people not access a particular attribute directly
(Nothing is stopping them, of course, but the intention is pretty clear).
Also, when someone subclasses your class, it makes accessing the
"privatized " attribute a little more difficult.
[color=blue][color=green][color=darkred]
>>> class C1:[/color][/color][/color]
.... def __init__(self, value=1):
.... self.__value = value
....[color=blue][color=green][color=darkred]
>>> class C2(C1):[/color][/color][/color]
.... def __init__(self):
.... C1.__init__(sel f)
....[color=blue][color=green][color=darkred]
>>> c2 = C2()
>>> dir(c2)[/color][/color][/color]
['_C1__value', '__doc__', '__init__', '__module__']
# ^^^^^^^^^^^
# Here's the "private" attribute


Personally, I use single underscore to denote "protected" , and double
underscore to denote "private" (if I use them at all).

HTH
Sean

[Daniel Klein]

Re: Which way to say 'private'?

On Thu, 21 Aug 2003 11:42:02 -0400, "Sean Ross"
<sross@connectm ail.carleton.ca > wrote:
[color=blue]
>"Daniel Klein" <danielk@aracne t.com> wrote in message
>news:14f9kv4fv uf67k6j12lpgt6v k9dcpefchm@4ax. com...[color=green]
>> There are 2 ways to indicate private members of classes, by prepending
>> 1 or 2 underscore characters, the latter causing name mangling. My
>> question is: When would I use which kind to indicate privacy?[/color]
>
>Personally, I use single underscore to denote "protected" , and double
>underscore to denote "private" (if I use them at all).[/color]

Thanks for the courtesy or your reply, Sean.

I should probably have mentioned that I am concerned about advertising the
'public' interface (so that users of the class know how best to use it and
what my intentions were) more than 'restricting' access to 'private' members,
which we all know is pretty much pointless in Python ;-)

Thanks again,

Dan

[A. Lloyd Flanagan]

Re: Which way to say 'private'?

Daniel Klein <danielk@aracne t.com> wrote in message news:<14f9kv4fv uf67k6j12lpgt6v k9dcpefchm@4ax. com>...[color=blue]
> There are 2 ways to indicate private members of classes, by prepending
> 1 or 2 underscore characters, the latter causing name mangling. My
> question is: When would I use which kind to indicate privacy?
>
> Thanks,
> Daniel Klein
> Member of the Dead Parrot Society[/color]

Well, one underscore is sort of a gentleman's agreement, it's like a
suggestion "you really should think before you touch this". Two
underscores is a stronger suggestion, like "I don't want you to touch
this and you'll have to go through hoops to do it".
Personally I always use two underscores for class-level data, and
write accessor methods.
One underscore is useful in a package-level declaration to prevent it
from being exported.
Hope this helps.

[Jacek Generowicz]

Re: Which way to say 'private'?

Daniel Klein <danielk@aracne t.com> writes:
[color=blue]
> On Thu, 21 Aug 2003 11:42:02 -0400, "Sean Ross"
> <sross@connectm ail.carleton.ca > wrote:
>[color=green]
> >"Daniel Klein" <danielk@aracne t.com> wrote in message[/color]
>[color=green]
> >Personally, I use single underscore to denote "protected" , and double
> >underscore to denote "private" (if I use them at all).[/color][/color]

This is not the orthodox convention: single underscore indicates
"privacy" (more accurately: "this isn't part of the interface"):
double underscore is actually a mechanism for avioiding name clashes.
[color=blue]
> I should probably have mentioned that I am concerned about advertising the
> 'public' interface (so that users of the class know how best to use it and
> what my intentions were) more than 'restricting' access to 'private' members,
> which we all know is pretty much pointless in Python ;-)[/color]

Definitely single underscore.

(Also, remember that, with properties, you can have things which look
like direct attributes actulally be set and read with setter and
getter functions, so it is perfectly OK to make data attributes be
part of the interface, as you can later install getters and setters
for them without changing the interface.)