classification
Title: ``dir`` function does not work correctly with classes.
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.2, Python 3.3, Python 3.4
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Ramchandra Apte, davidhalter, ethan.furman, r.david.murray
Priority: normal Keywords:

Created on 2013-09-11 06:20 by davidhalter, last changed 2013-09-11 17:22 by r.david.murray. This issue is now closed.

Messages (7)
msg197471 - (view) Author: David Halter (davidhalter) Date: 2013-09-11 06:20
I recently stumbled over the ``dir`` function not working correctly with classes. This means that ``dir(object)`` won't list ``object.__bases__`` or ``object.__subclasses`` (and many other useful methods).

I think that we should change that. The C function ``type_dir`` (in ``Objects/typeobject.c``) has a documentation entry which states:

"We deliberately don't suck up its __class__, as methods belonging to the metaclass would probably be more confusing than helpful."

I think that that's not true. The current behaviour of ``dir`` is way more confusing, since ``dir`` is typically the tool how we find out about magic methods.

I wrote about it in more details here: http://jedidjah.ch/code/2013/9/8/wrong_dir_function/
msg197488 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-09-11 11:28
As far as I know dir has always worked this way with classes (certainly back as far as 2.4, which is the oldest python I have on my dev system).  So I doubt that this behavior can be open to change, whether or not we think the original decision was correct.
msg197491 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2013-09-11 13:36
It's going to take more than "I think that that's not true," to get a change made.

From http://docs.python.org/2/library/functions.html#dir :
> 
> Because dir() is supplied primarily as a convenience for use at an
> interactive prompt, it tries to supply an interesting set of names
> more than it tries to supply a rigorously or consistently defined
> set of names [...] .

Currently, `dir(cls)` returns information that tells us how instances of that class will behave.  Because metaclass methods have no direct effect on instance behavior, having dir return metaclass methods and attributes would be confusing.

If you want to know how a class is going to behave you need to `dir(cls.__class__)`.
msg197493 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2013-09-11 15:55
-1 classes themselves are objects, so dir should list the attributes/methods of the class object, not the instances.
msg197496 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2013-09-11 16:11
So when you do a `dir(int)` you don't want to know what you can call on 7?  You'd rather know what you can call on 'type'?
msg197497 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2013-09-11 16:13
On 11 September 2013 21:41, Ethan Furman <report@bugs.python.org> wrote:

>
> Ethan Furman added the comment:
>
> So when you do a `dir(int)` you don't want to know what you can call on 7?
>  You'd rather know what you can call on 'type'?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue19002>
> _______________________________________
>

Yes, as that is more consistent.
msg197498 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-09-11 17:22
That's not how people use it at the interactive prompt, though.  I call dir(str) to find what methods I can call on an str object, not what methods I can call on the str class object. Same goes for my own classes.  Yes, I also call it on instances, but it would be very surprising, especially at this point in Python's history, for this to change.

It would also screw up pydoc and inspect.  Screwing up inspect is an issue Ethan has already brought up as a possible problem regardless, but that doesn't really enter into this discussion, because those two examples indicate how badly such a change would break existing python code outside the stdlib.

I'm going to close this issue as rejected.  The provision of a differently named builtin with the alternate semantics requested here could be raised on python-ideas, but I doubt it will get much traction since you can just do dir(xxx.__class__ for the rare cases where you want that info.

Aside: I haven't looked at what jedi is, but perhaps you need to rethink your dependence on dir, just as we (may be?) rethinking inspect's dependence on dir.
History
Date User Action Args
2013-09-11 17:22:10r.david.murraysetstatus: open -> closed
resolution: rejected
messages: + msg197498

stage: resolved
2013-09-11 16:13:54Ramchandra Aptesetmessages: + msg197497
2013-09-11 16:11:46ethan.furmansetmessages: + msg197496
2013-09-11 15:55:27Ramchandra Aptesetnosy: + Ramchandra Apte
messages: + msg197493
2013-09-11 13:36:11ethan.furmansetmessages: + msg197491
2013-09-11 11:28:31r.david.murraysetnosy: + r.david.murray
messages: + msg197488
2013-09-11 07:35:21ethan.furmansetversions: - Python 2.6, Python 3.1, Python 2.7, Python 3.5
2013-09-11 07:34:21ethan.furmansetnosy: + ethan.furman
2013-09-11 06:20:51davidhaltercreate