Re: [Python-Dev] __dir__, part 2
Guido van Rossum wrote:
>> (what about vars(), btw?)
>
> Interesting question! Right now vars() and dir() don't seem to use the
> same set of keys; e.g.:
>
class C: pass
> ...
c = C()
c.foo = 42
vars(c)
> {'foo': 42}
dir(c)
> ['__doc__', '__module__', 'foo']
>
> It makes some sense for vars(x) to return something like
>
> dict((name, getattr(x, name)) for name in dir(x) if hasattr(x, name))
>
> and for the following equivalence to hold between vars() and dir() without
> args:
>
> dir() == sorted(vars().keys())
+1. This is easy and straightforward to explain, better than
"With a module, class or class instance object as argument (or anything else
that has a __dict__ attribute), returns a dictionary corresponding to the
object's symbol table."
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __dir__, part 2
Fredrik Lundh wrote: > Guido van Rossum wrote: > >> No objection on targetting 2.6 if other developers agree. Seems this >> is well under way. good work! > > given that dir() is used extensively by introspection tools, I'm > not sure I'm positive to a __dir__ that *overrides* the standard > dir() behaviour. *adding* to the default dir() list is okay, re- > placing it is a lot more questionable. If the new default __dir__ implementation only yields the same set of attributes (or more), there should be no problem. If somebody overrides __dir__, he knows what he's doing. He will most likely do something like "return super.__dir__() + [my, custom, attributes]". regards, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __dir__, part 2
Fredrik Lundh wrote: > Guido van Rossum wrote: > >> No objection on targetting 2.6 if other developers agree. Seems this >> is well under way. good work! > > given that dir() is used extensively by introspection tools, I'm > not sure I'm positive to a __dir__ that *overrides* the standard > dir() behaviour. *adding* to the default dir() list is okay, re- > placing it is a lot more questionable. If a class only overrides __getattr__, then I agree it should only add to __dir__ (most likely by using a super call as Georg suggests). If it overrides __getattribute__, however, then it can actually deliberately block access to attributes that would otherwise be accessible, so it may make sense for it to alter the basic result of dir() instead of just adding more attributes to the end. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
