Author neologix
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.06:51:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM1rVpR1OV7svaFE+sN_ZnymONquf5O4Z4C9Zr9oj127ig@mail.gmail.com>
In-reply-to <1367790202.96.0.70313907442.issue11406@psf.upfronthosting.co.za>
Content
> Charles gave this example of code that would fall over:
>
> size = 0
> for name, st in scandir(path):
>     if stat.S_ISREG(st.st_mode):
>         size += st.st_size
>
> I don't see it, though. In this case you need both .st_mode and .st_size, so a caller would check that those are not None, like so:

Well, that's precisely the point.
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...). By
returning a dummy stat object, you break the stat interface, and I'm
positive this *will* puzzle users and introduce errors.

Now, if I'm the only one who finds this trick dangerous and ugly, you
can go ahead, but I stand by my claim that it's definitely a bad idea
(between this and the explicit Enum value assignent, I feel somewhat
lost lately :-)
History
Date User Action Args
2013-05-06 06:51:57neologixsetrecipients: + neologix, loewis, twouters, rhettinger, terry.reedy, gregory.p.smith, ncoghlan, pitrou, vstinner, giampaolo.rodola, christian.heimes, tim.golden, eric.araujo, Trundle, brian.curtin, benhoyt, torsten, nvetoshkin, abacabadabacaba, socketpair, serhiy.storchaka
2013-05-06 06:51:56neologixlinkissue11406 messages
2013-05-06 06:51:56neologixcreate