> Guido> The latest proposal is to let dir() return more rather than less:
> Guido> it will return the instance variable names *plus* all attributes
> Guido> defined by the class *and* its base classes.
>
> While that may seem like a step in the right direction, it will still break
> things and not obviate the need for some sort of warning.
Unclear. If you look it up, you'll find that dir() is documented very
vaguely. It returns a list of strings, and the strings in that list
are attributes of the object -- that's about it. If someone wrote
code that relied on this returning a specific set of strings, they get
what they deserve.
Suppose this idea had started differently: as an improvement to dir(),
to make it return all the attributes (or at least all the ones that
are reasonably discoverable). I don't think anyone would complain.
> Also, one might
> argue that for interactive use it might be less helpful than the current
> behavior for users to be overwhelmed with dir() output. I have these two
> functions available to me in interactive sessions:
>
> def dir(o=globals,showall=0):
> if not showall and hasattr(o, "__all__"):
> x = list(o.__all__)
> x.sort()
> return x
> from __builtin__ import dir
> return dir(o)
>
> def dirall(o, showall=0):
> attrs = dir(o, showall)
> if hasattr(o, "__bases__"):
> for b in o.__bases__:
> attrs.extend(dirall(b, showall))
> if hasattr(o, "__class__") and o != o.__class__:
> attrs.extend(dirall(o.__class__, showall))
> adict = {}
> for a in attrs:
> adict[a] = 1
> attrs = adict.keys()
> attrs.sort()
> return attrs
>
> If I execute "dirall(gtk.GtkRadioButton())" I get a list with 175 entries.
> Granted, that's an extreme, but it suggests that in some cases the output of
> a recursive dir won't be all that helpful.
If interactive behavior changes, that can't be claimed to be "breaking
old code". It doesn't take very long to get used to a different way
of introspecting objects.
> What might be useful is to add a recursive flag to dir so that people can
> ask for everything. That way current behaviour would be preserved but users
> could get everything if they wanted to.
But "current behavior" is inconsistent. For some objects it includes
instance variables and methods. For other objects it includes only
instance variables. How useful is that?
If an object has 175 methods, you need a class browser -- neither a
recursive dir() nor a non-recursive dir() is very useful in that case.
I would prefer to see help() improved to the point where it can be
used for this purpose.
I think I've heard just about every argument there is about dir(). In
2.1 and before, it is an ill-defined mess of a function. We can
either try to give it a useful well-defined meaning, or deprecate it
altogether. The only two useful well-defined meanings that I can see
are either a sorted list of the keys of the argument's __dict__ (as
implemented in Python 2.2a1), or a sorted list of *all* the
discoverable attributes of the object. I actually prefer the first
for myself, but this received lots of complaints about how returning
[] for list instances would break code, so I am now proposing the
second well-defined meaning. I find it hard to imagine how returning
*more* names would still break code -- that code cannot have been very
robust in the first place.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4