[Python-bugs-list] [ python-Feature Requests-619222 ] os.listdir-alike that includes file type

[noreply@sourceforge.net]

Feature Requests item #619222, was opened at 2002-10-06 14:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=619222&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.listdir-alike that includes file type

Initial Comment:
I propose to add two new functions, say os.listdirtypes
and os.llistdirtypes.  These would be similar to
os.listdir except they would return a list of tuples
(filename, filetype).  This would have the advantage
that on oses that support the d_type entry in the
dirent struct the type could be calculated without
extra calls and harddrive reading.  Even on
non-supporting os/filesystems, it could emulate it with
a call to stat/lstat in the func, still saving some
work of calling stat and interpreting its result in
python code or using os.path.isX.

Filetype would indicate wether the entry was a file,
directory, link, fifo, etc.  This could either be a
char (like ls -l gives) ('-', 'd', 'l', 'p', etc), or
some sort of constant (os.DT_REG, os.DT_DIR, os.DT_LNK,
os.DT_FIFO, etc).  Personally I think the string method
is simpler and easier, though some (non-*ix) people may
be confused by '-' being file rather than 'f'.  (Of
course, you could change that, but then *ix users would
be confused ;)

listdirtypes would be equivalent to using stat, ie.
symlinks would be followed when determining types, and
llistdirtypes would be like lstat so symlinks would be
indicated as 'l'.

An app I'm working on right now that reads in a
directory tree on startup got about a 2.2x speedup when
I implemented this as an extension module, and about
1.6x speedup when I tested it without d_type support. 
(The module was written using Pyrex, so its not a
candidate for inclusion itself, but I would be willing
to work on a C implementation if this idea is accepted..)

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-10-13 16:08

Message:
Logged In: YES 
user_id=21627

I'm in favour of exposing more information received from
readdir. I'm not sure whether adding new functions is the
right API, perhaps adding a flag to the existing listdir is
sufficient.

I don't think listdir should perform stat calls itself; if
the system has some information available, fine, if it
doesn't, return nothing.

What is the proposed difference between listdirtypes and
llistdirtypes?

On the return type of the "verbose" listdir, I think it
should return structs with named fields, such as d_ino,
d_name, and d_type. Callers can then find out themselves
what information they got, and augment this with information
from stat that they also need. In particular, d_type should
be returned as presented in the system, since it might have
slight semantic difference to what os.stat would tell about
the file.

This should extend to other systems as well. E.g. on
Windows, it is possible to learn the modification times from
listdir, with no extra overhead.

There should also be a way to use this with os.path.walk.

So, in short, I'm in favour of this idea. Would you
volunteer to write a PEP, and provide the Unix implementation?

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

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