Author benhoyt
Recipients Trundle, abacabadabacaba, benhoyt, brian.curtin, christian.heimes, eric.araujo, giampaolo.rodola, gregory.p.smith, loewis, ncoghlan, neologix, nvetoshkin, pitrou, rhettinger, serhiy.storchaka, socketpair, terry.reedy, tim.golden, torsten, twouters, vstinner
Date 2013-05-06.09:08:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1367831336.15.0.223604857326.issue11406@psf.upfronthosting.co.za>
In-reply-to
Content
> 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...
History
Date User Action Args
2013-05-06 09:08:56benhoytsetrecipients: + benhoyt, loewis, twouters, rhettinger, terry.reedy, gregory.p.smith, ncoghlan, pitrou, vstinner, giampaolo.rodola, christian.heimes, tim.golden, eric.araujo, Trundle, brian.curtin, torsten, nvetoshkin, neologix, abacabadabacaba, socketpair, serhiy.storchaka
2013-05-06 09:08:56benhoytsetmessageid: <1367831336.15.0.223604857326.issue11406@psf.upfronthosting.co.za>
2013-05-06 09:08:56benhoytlinkissue11406 messages
2013-05-06 09:08:55benhoytcreate