This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients gregory.p.smith
Date 2015-03-03.01:16:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1425345371.02.0.709789700046.issue23567@psf.upfronthosting.co.za>
In-reply-to
Content
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
>>> import os, stat
>>> os.stat('/')
posix.stat_result(st_mode=16877, st_ino=2, st_dev=64513L, st_nlink=29, st_uid=0, st_gid=0, st_size=4096, st_atime=1425341751, st_mtime=1424824650, st_ctime=1424824650)
>>> x =os.stat('/')
>>> x.st_mtime
1424824650.653934
>>> x[stat.ST_MTIME]
1424824650
>>> os.stat_result
<type 'posix.stat_result'>


I have also confirmed the same behavior in 3.4.2.

This may be intentional.  Tuple [stat.ST_XXX] access to the stat return value is the old legacy way to access these prior to Python 2.2 when the stat_result object was introduced.  At that point they were likely all ints.

The os.stat_float_times() API exists to change the behavior of stat_result objects to return ints instead of floats by default, but the behavior of the tuple indexed values is always ints.

We need to explicitly document this behavior difference.  Changing the legacy tuple indexing behavior to return a float would likely break code.

Why file this?  We just ran into a bug due to code comparing a [stat.ST_MTIME] value to a stored stat_result.st_mtime thus continually reporting a difference due to the precision difference between the two but the numeric comparison doing its job regardless.
History
Date User Action Args
2015-03-03 01:16:11gregory.p.smithsetrecipients: + gregory.p.smith
2015-03-03 01:16:11gregory.p.smithsetmessageid: <1425345371.02.0.709789700046.issue23567@psf.upfronthosting.co.za>
2015-03-03 01:16:10gregory.p.smithlinkissue23567 messages
2015-03-03 01:16:09gregory.p.smithcreate