Ben Hoyt added the comment:
> A normal "caller" would never expect a stat object to be partially populated:
> if a function has a prototype returning a stat object, then I definitely
> expect it to be a regular stat object, with all the fields guaranteed by
> POSIX set (st_size, st_ino, st_dev...).
I don't think that's true in general, or true of how other Python APIs work.
For instance, many APIs return a "file-like object", and you can only do
certain things on that object, depending on what the documentation says, or
what EAFP gets you. Some file-like object don't support seek/tell, some don't
support close, etc. I've seen plenty of walk-like-a-duck checks like this:
if hasattr(f, 'close'):
f.close()
Anyway, my point boils down to:
* scandir() is a new function, so there aren't old trends or things that will
break
* we clearly document it as returning a tuple of (name, st), where st is a
"stat-like object" whose invididual fields are None if they couldn't be
determined for free with the directory scanning
* in fact, that's kind of the point of the "st" object in this function, so the
example could be the one I gave above where you call os.stat() if either of the
fields you want is None
* if that's clear in the documentation (of this new function) and the first
example shows you exactly how it's meant to be used, I think that's pretty sane
and sensible...
----------
_______________________________________
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
