Charles-François Natali added the comment: > I'd slightly prefer the name iterdir_stat(), as that almost makes the (name, > stat) return values explicit in the name. But that's kind of bikeshedding -- > scandir() works too.
I find iterdir_stat() ugly :-) I like the scandir name, which has some precedent with POSIX. > That's right: if we have a separate scandir() that returns (name, stat) > tuples, then a plain iterdir() is pretty much unnecessary -- callers just > ignore the second stat value if they don't care about it. Hum, wait. scandir() cannot return (name, stat), because on POSIX, readdir() only returns d_name and d_type (the type of the entry): to return a stat, we would have to call stat() on each entry, which would defeat the performance gain. And that's the problem with scandir: it's not portable. Depending on the OS/file system, you could very well get DT_UNKNOWN (and on Linux, since it uses an adaptive heuristic for NFS filesystem, you could have some entries with a resolved d_type and some others with DT_UNKNOWN, on the same directory stream). That's why scandir would be a rather low-level call, whose main user would be walkdir, which only needs to know the entry time and not the whole stat result. Also, I don't know which information is returned by the readdir equivalent on Windows, but if we want a consistent API, we have to somehow map d_type and Windows's returned type to a common type, like DT_FILE, DT_DIRECTORY, etc (which could be an enum). The other approach would be to return a dummy stat object with only st_mode set, but that would be kind of a hack to return a dummy stat result with only part of the attributes set (some people will get bitten by this). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11406> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
