[Python-Dev] dir, part 2 (original) (raw)

tomer filiba tomerfiliba at gmail.com
Mon Nov 6 22:55:11 CET 2006

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 <guido at python.org> 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 tpfoo in the type object, and I recommend doing it that way since the tpfoo 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: > (*) builtindir calls PyObjectDir 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: > (*) builtindir, if called without an argument, returns the frame's locals > (*) otherwise, it calls PyObjectDir(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 PyObjectDir does today) > (*) builtindir would take care of sorting the list returned by PyObjectDir > > 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/)

More information about the Python-Dev mailing list