[ python-Feature Requests-925537 ] dir(mod) OK or use vars(mod).keys()?

[SourceForge.net]

Feature Requests item #925537, was opened at 2004-03-29 21:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: dir(mod) OK or use vars(mod).keys()?

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2004-03-30 23:09

Message:
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.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-30 17:28

Message:
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.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-03-30 00:11

Message:
Logged In: YES 
user_id=21627

I fail to see a bug. Which specific usage of dir() does not
work as intended?

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 21:58

Message:
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


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 21:39

Message:
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().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470