I want to see all the variables

[johnf]

Hi,
When I use dir() I don't see the __ underscore items. Is there anything
that will show all the private vars and functions?

johnf

[Larry Bates]

johnf wrote:

Hi,
When I use dir() I don't see the __ underscore items. Is there anything
that will show all the private vars and functions?

johnf

The idea of the underscore items is that they aren't to be used by
you. If you wish to access private variables and functions you will
almost certainly have to look at the source code to make sure of
what they are and how they can be utilized.

-Larry

[wittempj]

What do you mean? Can you specify which special functions you don't
see?
I get:
pyclass X:
pass
pydir(X)
['__doc__', '__module__']
pyclass X:
def __getitem__(sel f, x):
pass
pydir(X)
['__doc__', '__getitem__', '__module__']

On Dec 29, 12:35 pm, johnf <jfabi...@yolo. comwrote:

Hi,
When I use dir() I don't see the __ underscore items. Is there anything
that will show all the private vars and functions?

johnf

[Steven D'Aprano]

On Fri, 29 Dec 2006 07:57:30 -0800, wi******@hotmai l.com wrote:

What do you mean? Can you specify which special functions you don't
see?
I get:
pyclass X:
pass
pydir(X)
['__doc__', '__module__']

How about these?

>>X.__dict__

{'__module__': '__main__', '__doc__': None}

>>X.__name__

'X'

>>X.__bases__

()

Now that's interesting... if __name__ and __bases__ don't live in the
class __dict__, where do they live? What other methods and attributes are
invisibly in X?
--
Steven.

[Steven D'Aprano]

On Fri, 29 Dec 2006 08:20:22 -0600, Larry Bates wrote:

johnf wrote:

>Hi,
When I use dir() I don't see the __ underscore items. Is there anything
that will show all the private vars and functions?

johnf

The idea of the underscore items is that they aren't to be used by
you.

Double leading+trailin g underscore attributes are NOT private, they are
*special* but public (e.g. __dict__, __class__, __str__, etc.). If you
don't believe me, have a look at dir(int) and count the underscored
attributes listed. Then try to find __dict__, __name__, __bases__,
__base__ or __mro__ within the list. Why are they suppressed?

But even if underscored attributes were private, the Python philosophy is
that private attributes are private by convention only -- even
name-mangled __private methods can be reached if you know how.

If you wish to access private variables and functions you will
almost certainly have to look at the source code to make sure of
what they are and how they can be utilized.

Not so.

>>class Parrot(object):

.... def _private(self):
.... """Private method, returns a magic string."""
.... return "Don't touch!!!"
....

>>Parrot._priva te.__doc__

"Private method, returns a magic string."

--
Steven.

[wittempj]

On Dec 29, 5:17 pm, Steven D'Aprano
<[e-mail] IS.cybersource. com.auwrote:

On Fri, 29 Dec 2006 07:57:30 -0800, witte...@hotmai l.com wrote:

What do you mean? Can you specify which special functions you don't
see?
I get:
pyclass X:
pass
pydir(X)
['__doc__', '__module__']How about these?

>X.__dict__{'__ module__': '__main__', '__doc__': None}>>X.__name __

'X'

>X.__bases__( )

Now that's interesting... if __name__ and __bases__ don't live in the
class __dict__, where do they live? What other methods and attributes are
invisibly in X?

--
Steven.

Well, then we have to lookup what dir() does --
http://docs.python.org/lib/built-in-funcs.html -- it tries to bring up
the interesting attributes of an object, apparently __name__ and
__bases__ are considered to be not so interesting....

[johnf]

Steven D'Aprano wrote:

On Fri, 29 Dec 2006 08:20:22 -0600, Larry Bates wrote:

>johnf wrote:

>>Hi,
When I use dir() I don't see the __ underscore items. Is there anything
that will show all the private vars and functions?

johnf

The idea of the underscore items is that they aren't to be used by
you.

Double leading+trailin g underscore attributes are NOT private, they are
*special* but public (e.g. __dict__, __class__, __str__, etc.). If you
don't believe me, have a look at dir(int) and count the underscored
attributes listed. Then try to find __dict__, __name__, __bases__,
__base__ or __mro__ within the list. Why are they suppressed?

But even if underscored attributes were private, the Python philosophy is
that private attributes are private by convention only -- even
name-mangled __private methods can be reached if you know how.

>If you wish to access private variables and functions you will
almost certainly have to look at the source code to make sure of
what they are and how they can be utilized.

Not so.

>>>class Parrot(object):

... def _private(self):
... """Private method, returns a magic string."""
... return "Don't touch!!!"
...

>>>Parrot._priv ate.__doc__

"Private method, returns a magic string."

Ok then how do debug when I have something like "__source" and I need to
know what is available for the object?

John

[Steven D'Aprano]

On Fri, 29 Dec 2006 12:04:11 -0800, johnf wrote:

Ok then how do debug when I have something like "__source" and I need to
know what is available for the object?

Outside of a class, objects with two leading underscores are just ordinary
objects with no special behaviour:

>>__source = 2
__source

2

Objects with a single leading underscore like _source are slightly
special: if you do "from module import *" any names with a single leading
underscore are not imported.

Class attributes with two leading underscores like __source are considered
private to the class, so in general you shouldn't need to know anything
about them. To enforce that, Python mangles the name so it is harder to
reach.

But if/when you do need to get to them, they are easy to get to:

>>class Spam:

.... __attribute = 2
....

>>Spam().__attr ibute

Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: Spam instance has no attribute '__attribute'

>>Spam()._Spam_ _attribute

2

Notice that Python doesn't generally try to hide "private" attributes:

>>dir(Spam)

['_Spam__attribu te', '__doc__', '__module__']

There are three other underscore conventions in use:

(1) Objects with a single leading underscore like _attribute are private
by convention, but Python doesn't enforce it. Starting an object with a
single underscore is like writing "# Private! Don't touch!" after it.

(2) By convention, if you want to create a name that is the same as a
built-in object without shadowing (hiding) the built-in, put a single
trailing underscore after it like "file_". That's just a style convention
though, you are free to call it FiLE ,or anything else, if you prefer.

(3) Last but not least, class attributes with two leading and trailing
underscores are considered special but public, like __init__ and __repr__.
It is probably a bad idea to invent your own.

--
Steven.

[Gabriel Genellina]

At Friday 29/12/2006 13:17, Steven D'Aprano wrote:

>X.__dict__

{'__module__ ': '__main__', '__doc__': None}

>X.__name__

'X'

>X.__bases__

()

Now that's interesting... if __name__ and __bases__ don't live in the
class __dict__, where do they live? What other methods and attributes are
invisibly in X?

They live in the C structure implementing the type; members tp_bases
and tp_name respectively. Most predefined type/class attributes have
an slot for storing its value, for efficiency. See include/object.h
--
Gabriel Genellina
Softlab SRL


_______________ _______________ _______________ _____
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[johnf]

Steven D'Aprano wrote:

>
There are three other underscore conventions in use:

(1) Objects with a single leading underscore like _attribute are private
by convention, but Python doesn't enforce it. Starting an object with a
single underscore is like writing "# Private! Don't touch!" after it.

(2) By convention, if you want to create a name that is the same as a
built-in object without shadowing (hiding) the built-in, put a single
trailing underscore after it like "file_". That's just a style convention
though, you are free to call it FiLE ,or anything else, if you prefer.

(3) Last but not least, class attributes with two leading and trailing
underscores are considered special but public, like __init__ and __repr__.
It is probably a bad idea to invent your own.

Very detailed. But I was attempting to debug some code which subclassed
other code. I got a traceback that something like "no
mySubClass.__so urce.query() did not exist". The superclass had something
like "myClass.__sour ce.query(sql)" which worked
but "mySubClass.__s ource.query(sql )" did not work. So I tried to debug
using "dir(myClass.__ source)" and got an error. And I also got error when
I "dir(mySubClass .__source". So how could I have debugged the problem if
dir() will not display information on the __source? I hope that explains
my issue.

Thanks
Johnf