[Python-Dev] __dir__, part 2

[Guido van Rossum]

Sounds like a good plan, though I'm not sure if it's worth doing in
2.6 -- I'd be happy with doing this just in 3k.

I'm not sure what you mean by "adding a method slot" -- certainly it's
possible to define a method __foo__ and call it directly without
having a special tp_foo in the type object, and I recommend doing it
that way since the tp_foo slots are just there to make things fast; in
this case I don't see a need for dir() to be fast.

--Guido

On 11/6/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> 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:
> http://mail.python.org/pipermail/python-dev/2006-July/067095.html
> which was generally accepted by the forum:
> http://mail.python.org/pipermail/python-dev/2006-July/067139.html
>
> 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"?
>
>
> -tomer
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


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