[issue23567] os.stat() tuple access vs named attribute access int vs float

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Python 2.7 is no longer supported.

--
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23567] os.stat() tuple access vs named attribute access int vs float

[Gregory P. Smith]

Gregory P. Smith added the comment:

I missed that because i was looking for it to be called out under 2.7 os.stat() 
docs rather than under 2.7's os.stat_float_times() which is a method nobody is 
likely to read the documentation for as floats have been the default since 2.5.

The 2.7 docs are much less organized around this than the 3.x.

Adding that note in the same paragraph on 2.7's os.stat() docs would be 
sufficient.

For backward compatibility, the return value of stat() is also accessible as a 
tuple of at least 10 integers implies it, but doesn't explicitly call out the 
integer [ST_XXX] vs float .st_xxx difference as adding that sentence does.

--
versions:  -Python 3.4, Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23567
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23567] os.stat() tuple access vs named attribute access int vs float

[Gregory P. Smith]

New submission from Gregory P. Smith:

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.

--
components: Library (Lib)
messages: 237099
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: os.stat() tuple access vs named attribute access int vs float
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23567
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23567] os.stat() tuple access vs named attribute access int vs float

[STINNER Victor]

STINNER Victor added the comment:

It's already documented:

https://docs.python.org/dev/library/os.html#os.stat_result

For compatibility with older Python versions, accessing stat_result as a tuple 
always returns integers.

--
nosy: +haypo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23567
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com