469,914 Members | 2,480 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,914 developers. It's quick & easy.

Solved: Question about idiomatic use of _ and private stuff.

On Friday, Feb 23rd 2007 at 11:12 -0500, quoth Steven W. Orr:

=>I understand that two leading underscores in a class attribute make the
=>attribute private. But I often see things that are coded up with one
=>underscore. Unless I'm missing something, there's a idiom going on here.
=>
=>Why do people sometimes use one leading underscore?

I found the answer. It turns out that if you say:

import foo

then you get access to all of the attributes that are not mangled. A
single leading underscore does not cause mangling.

If you say

from foo import _fooa, _foob,

then the import will fail because the _ is used only by the import to
decide that you shouldn't see _fooa or _foob.

--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
Feb 24 '07 #1
2 1061
On Fri, 23 Feb 2007 23:17:32 -0500, Steven W. Orr wrote:
On Friday, Feb 23rd 2007 at 11:12 -0500, quoth Steven W. Orr:

=>I understand that two leading underscores in a class attribute make the
=>attribute private. But I often see things that are coded up with one
=>underscore. Unless I'm missing something, there's a idiom going on here.
=>
=>Why do people sometimes use one leading underscore?

I found the answer.
Not quite.

It turns out that if you say:

import foo

then you get access to all of the attributes that are not mangled. A
single leading underscore does not cause mangling.

If you say

from foo import _fooa, _foob,

then the import will fail because the _ is used only by the import to
decide that you shouldn't see _fooa or _foob.
Incorrect.

Let's try it. From the shell:

$ cat data.py
fear = "The chief weapon of the Spanish Inquisition"
_parrot = "A green bird"
__spam = "A nasty treat"
And then from Python:
>>from data import fear, _parrot, __spam
fear
'The chief weapon of the Spanish Inquisition'
>>_parrot
'A green bird'
>>__spam
'A nasty treat'

Python only ignores _names when you call "from module import *".

Here are the underscore rules:

(1) In the interactive interpreter, the name "_" is automatically set to
the result of the last command.

(2) Names with a SINGLE lead underscore are ignored when you say "from
module import *". They are imported if you ask for them directly, and in
the normal "import module" form.

(3) Class attributes, but not other objects, with TWO leading underscores
have their names mangled by Python. E.g. Parrot.__method is mangled to
Parrot._Parrot__method.

(4) Names with two leading underscores and two trailing underscores may be
reserved for special methods (e.g. __init__, __str__, etc.) and objects
(e.g. __all__ in packages, __name__, etc.). While Python doesn't prohibit
you from creating your own methods with leading and trailing underscores,
it is discouraged.

(5) If you want to give an object a name which clashes with a built-in,
the convention is to append a single TRAILING underscore to the name (e.g.
print_).
Hope that's clear now.

--
Steven.

Feb 24 '07 #2
If you say
>
from foo import _fooa, _foob,

then the import will fail because the _ is used only by the import to
decide that you shouldn't see _fooa or _foob.
???

Read Python manuals, please.

Feb 24 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

220 posts views Thread by Brandon J. Van Every | last post: by
8 posts views Thread by Al Reynolds | last post: by
20 posts views Thread by Mark Harrison | last post: by
90 posts views Thread by John Salerno | last post: by
4 posts views Thread by Steven W. Orr | last post: by
12 posts views Thread by Matt B | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.