Message188492
| 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:57 | neologix | set | recipients:
+ 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:56 | neologix | link | issue11406 messages |
| 2013年05月06日 06:51:56 | neologix | create |
|