Python2.2 doesn't give members of a list

[Andrew Dalke]

Guido:
>The docs for dir() are very vague; code depending on a particular
>behavior must necessarily be built on observation.  For example, I'm
>not particularly concerned with breaking pydoc or PyChecker -- these
>are apps that heavily rely on introspection, and their authors were
>aware that they were walking on thin ice.  It's easy enough to fix
>these.
>
>I'd really like to see how people are using dir() in code that would
>break if it suddenly started to return all attributes; what kind of
>harm could be done?

I wrote one application similar to pydoc (acutually based off of Ping's
earlier code).  It uses dir two places.  They are:

 dir(module) -> list of elements in the module

and in a routine called 'superdir' which gets all of the class
methods and attributes:

def superdir(klass):
  klasses = [klass]
  terms = {}
  while klasses:
    klass = klasses[0]
    klasses = klasses[1:]
    for name in dir(klass):
      terms[name] = 1
    klasses.extend(list(klass.__bases__))
  names = terms.keys()
  names.sort()
  return names

As far as I can tell, none of the changes you mention will
change any of this code.

I also have access to one of my client's code base.  They use
'dir' precisely once in the whole system, which is for a function
called 'help' which works like the new pydoc.help command.  The
specific code is:

  if type(obj) == ModuleType:
     print "The following functions, classes, constants etc. are available "
\
           "in this module:"
     print
     list = []
     for name in dir(obj):
       if name[0:2] != "__":
         list.append(_describe(obj.__dict__[name], name))
     list.sort()
     for item in list:
       print item
     print "-" * 78

Again, since this works on a module and not a class, it will not
be affected by any of these changes to dir().  Besides, I expect
them to migrate to use pydoc's help command, so this will all
go away.

>If this is really unacceptable, [...]

I agree with Paul Boddie when he said:
> I was initially surprised that dir(object) didn't give
> the methods as well as the attributes, and disappointed that
> dir(object.__class__) doesn't state the methods available on that
> object.

I know I get annoyed when I'm trying to figure out what an
object does and I do a sequence like

dir(obj)
dir(obj.__class__)
obj.__class__.__bases__
dir(obj.__class__.__bases__[0])

(while all the time being thankful for readline support)

So I would like to change dir() to implement (quoting Guido again)
> How about making dir() incompatible in the other direction, and
> letting it return a sorted list of *all* attributes (that one can
> reasonably deduce)?

as that's is easier for people to use while also not likely to
break much existing code.

(I presented Python at a bioinformatics conference a couple weeks
ago.  One of the advantages I mentioned of Python was introspection
in the interactive mode, so you could puzzle some things out even if
there wasn't documentation.  I did omit describing that things
become a bit tricker with more complicated classes.  Ooops.  So
you wouldn't like them to think of me as overpromting Python,
would you?  ;)

Alex:
> That would be wonderful, but I think it would still require a
> from __future__ for one release.

Turning it around, another possibility is

from __past__ import dir

I am not proposing this - I only think it's cute, and works
fine because dir() is only a function, not a variable->keyword
change like yield.

                    Andrew
                    dalke at dalkescientific.com