[Python-Dev] __dir__, part 2

tomer filiba tomerfiliba at gmail.com
Mon Nov 6 16:02:51 CET 2006

so, if you remember, i suggested adding __dir__ to objects, so as to make
dir() customizable, remove the deprecated __methods__ and __members__,
and make it symmetrical to other built-in functions.

you can see the original post here:
which was generally accepted by the forum:

so i went on, now that i have some spare time, to research the issue.
the current dir() works as follows:
(*) builtin_dir calls PyObject_Dir to do the trick
(*) if the object is NULL (dir with no argument), return the frame's locals
(*) if the object is a *module*, we're just using it's __dict__
(*) if the object is a *type*, we're using it's __dict__ and __bases__,
but not __class__ (so as not to show the metaclass)
(*) otherwise, it's a "normal object", so we take it's __dict__, along with
__methods__, __members__, and dir(__class__)
(*) create a list of keys from the dict, sort, return

we'll have to change that if we were to introduce __dir__. my design is:
(*) builtin_dir, if called without an argument, returns the frame's locals
(*) otherwise, it calls PyObject_Dir(self), which would dispatch self.__dir__()
(*) if `self` doesn't have __dir__, default to object.__dir__(self)
(*) the default object.__dir__ implementation would do the same as
today: collect __dict__, __members__, __methods__, and dir(__class__).
by py3k, we'll remove looking into __methods__ and __members__.
(*) type objects and module objects would implement __dir__ to their
liking (as PyObject_Dir does today)
(*) builtin_dir would take care of sorting the list returned by PyObject_Dir

so first i'd want you people to react on my design, maybe you'd find
flaws whatever. also, should this become a PEP?

and last, how do i add a new method slot? does it mean i need to
change all type-object definitions throughout the codebase?
do i add it to some protocol? or directly to the "object protocol"?


More information about the Python-Dev mailing list