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 <[EMAIL PROTECTED]> 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@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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
