Issue 925537: dir(mod) OK or use vars(mod).keys()? (original) (raw)

Issue925537

Created on 2004-03-29 19:28 by jimjjewett, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (10)
msg54125 - (view)	Author: Jim Jewett (jimjjewett)	Date: 2004-03-29 19:28
The documentation on dir() notes that its behavior may change across releases. Several library modules use dir(x) in ways that might break if it changed too much. Should these be changed to use vars(obj).keys() (and possibly sort()), or should the note on dir() be removed? My own preference would just be to provide some guidance, such as "The output of dir() will always include all public variables which do not have a magic meaning." I realize that the standard library itself could be updated if dir() changes in an uncomfortable way. My real concern is which spelling to use in my own code. The library examples suggest a simpler (and clearer) dir(), but the documentation still says otherwise. A quick search for modules using dir() showed possible trouble in at least cgitb, cmd, FCNTL, inspect, optparse, os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, tokenize, unittest, and urllib2.
msg54126 - (view)	Author: Jim Jewett (jimjjewett)	Date: 2004-03-29 19:39
Logged In: YES user_id=764593 If there concern is over attributes that are "public" but don't exist until called, then most uses of dir and vars are already broken. An alternative reasonable promise would be The output of dir(obj) will always include all (public?, non-magical?) names in vars(obj).keys().
msg54127 - (view)	Author: Jim Jewett (jimjjewett)	Date: 2004-03-29 19:58
Logged In: YES user_id=764593 Correction: "The output of dir (module) will always include ..." The most common use is figuring out what to do with (import from) a module. Symmetry suggests the same for a no-argument call or a class or type object, but object instances do not use their __dict__ for their attributes; the results are already different there. -jJ
msg54128 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2004-03-29 22:11
Logged In: YES user_id=21627 I fail to see a bug. Which specific usage of dir() does not work as intended?
msg54129 - (view)	Author: Jim Jewett (jimjjewett)	Date: 2004-03-30 15:28
Logged In: YES user_id=764593 The ideal fix would be in documentation (and therefore policy). I want to do something like import_list = [x for x in dir(other_mod) if wanted(x)] It happens to work today on my machine, but the documentation says that dir(x) may return different results in different releases. This means that I can't safely use it in released code. If there were some indication that dir(module) would continue to return the same names as vars(module).keys(), then I could use it. If the differences were only in variables not intended for export, that would also be OK -- but dir does not current promise this.
msg54130 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2004-03-30 21:09
Logged In: YES user_id=21627 Ok, marking it as a feature request then: Explicitly pointing out that behaviour may change in the future has usually been done because change in behaviour is anticipated, or has happened in the past. Giving stronger guarantees about future versions a feature that is currently not provided.
msg54131 - (view)	Author: Tim Peters (tim.peters) *	Date: 2004-03-31 00:51
Logged In: YES user_id=31435 Ya, dir() was *intended* to be a convenience for use at the interactive shell. I expect the only promise Guido wants to make about it is that it will show him stuff he finds interesting as Python changes <0.7 wink>.
msg54132 - (view)	Author: Raymond Hettinger (rhettinger) *	Date: 2004-05-21 06:05
Logged In: YES user_id=80475 One possible change is in the works. Someone, suggested that dir() starting including the __name__ attribute.
msg54133 - (view)	Author: Neal Norwitz (nnorwitz) *	Date: 2007-03-16 06:02
Has anything happened? Is this still relevant?
msg54134 - (view)	Author: Georg Brandl (georg.brandl) *	Date: 2007-03-16 08:31
Now that we have __dir__(), I think this is "rejected".