Charles-François Natali added the comment: > 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 :-) ---------- _______________________________________ 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
