Python2.2 doesn't give members of a list

[Guido van Rossum]

"Alex Martelli" <aleaxit at yahoo.com> writes:

> > Hm.  How about making dir() incompatible in the other direction, and
> > letting it return a sorted list of *all* attributes (that one can
> 
> That would be wonderful, but I think it would still require a from
> __future__
> for one release.

Let me try to argue against this.  A future statement is a big stick.
It requires a relatively large amount of effort on the implementation
side, and every user has to add a fairly ugly thing to their code if
they want the new feature.  Also, if I may believe the arguments that
were used against changing division, one release wouldn't be enough,
since many people may make the jump right from
1.5.2 to 2.7 (for example).

I'm trying hard to make the type/class unification sufficiently
backwards compatible that it won't need a future statement; instead, I
try to look for more subtle clues.  For example, in order to declare a
new-style class, you use "class C(object)" or "__metaclass__ = type".

Regarding dir(): 

I'm expecting that uses of dir() fall in two categories: interactive
use, and programming tools.  A future statement won't help interactive
use -- you just have to retrain your fingers, big deal.  Programming
tools are generally specific to a particular version anyway, and can
easily be updated (they don't stay behind when the programmer leaves).

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 could also change dir() to return either the keys of the instance
dict or the keys of the class dict, whichever is found first.  That
would be even closer to the old behavior, yet still more rational.

If this is really unacceptable, an alternative to a future statement
would be to provide the new implementation of dir() in a separate
module (not __future__).  In the past, for years the built-in dir()
was much less powerful (it only worked on modules), and there was a
module "newdir" that provided a dir() function along the lines of the
current one.  This is much less work than a future statement because
every change to the future statement requires some modifications to
the parser so that it can issue a proper diagnostic.

--Guido van Rossum (home page: http://www.python.org/~guido/)