cool. first time i build the entire interpreter, 'twas fun :) currently i "retained" support for __members__ and __methods__, so it doesn't break anything and is compatible with 2.6.
i really hope it will be included in 2.6 as today i'm using ugly hacks in RPyC to make remote objects appear like local ones. having __dir__ solves all of my problems. besides, it makes a lot of sense of define __dir__ for classes that define __getattr__. i don't think it should be pushed back to py3k. here's the patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1591665&group_id=5470&atid=305470 here's a demo: >>> class foo(object): ... def __dir__(self): ... return ["kan", "ga", "roo"] ... >>> f = foo() >>> f <__main__.foo object at 0x00A90C78> >>> dir() ['__builtins__', '__doc__', '__name__', 'f', 'foo'] >>> dir(f) ['ga', 'kan', 'roo'] >>> dir(foo) ['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__getattribute__ ', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__ ', '__repr__', '__setattr__', '__str__', '__weakref__'] >>> class bar(object): ... __members__ = ["bow", "wow"] ... >>> b=bar() >>> dir(b) ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__hash_ _', '__init__', '__members__', '__module__', '__new__', '__reduce__', '__reduce_ ex__', '__repr__', '__setattr__', '__str__', '__weakref__', 'bow', 'wow'] -tomer On 11/6/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > 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
