Guido van Rossum writes:
| Tommy:
| > > ... did I hear that attributes of an object that begin with an
| > > underscore ('_') are not supposed to show up when you do a dir() on
| > > that object? I believe I heard this was coming and it has yet to be
| > > implemented. Will it be implemented any time soon? And if it is,
| > > will these attributes show up if I do a vars() on the object?
|
| Steven Majewski:
| > I believe the current case is that objects starting with underscore
| > are not imported into the current namespace by a "from module import *"
| > statement, but everything is visible via a dir(module). ( and even
| > names that are not apparently/obviously visible like obj.__methods__
| > or something.__members__ or namespaceobj.__dict__ are always reachable/
| > readable - at least until 'access' get's promoted out of experimental!)
| >
| > I don't recall a change in this being discussed.
| > ( Did I miss something while I was away? )
|
| Hm. I hope Tommy just phrased his wish as a rumor. It certainly
| didn't orginate with me and I haven't heard of it either.
|
| > It might not be a bad idea, though. Now that we also have 'vars()',
| > they could be further distinguished by dir() ignoring the private
| > names. I haven't looked at the code to see if this would be easy to
| > implement yet.
|
| It would be easy enough, but I don't think I like it. I sort of like
| the idea that vars().keys() == dir(). That would mean that if dir()
| is changed, vars() would also have to be changed (and that *is* more
| work as it currently returns a pointer to an existing dictionary). In
| any case both functions should then have an optional flag argument to
| show everything.
|
| But why would you want this? What's the point in not seeing there's a
| local variable "_foo" when one exists?
|
| --Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
| <URL:http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>
-------> Tommy.
"I am who I am who I am. Well, who am I?" -- Dave Matthews