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.

classification
Title: access to st_rdev,st_blocks,st_blksize
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: cblake, gvanrossum
Priority: normal Keywords: patch

Created on 2001-12-17 03:46 by cblake, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
py-stat.d cblake, 2001-12-17 03:46 patch to permit access to ST_RDEV,ST_BLOCKS,ST_BLKSIZE
Messages (2)
msg38488 - (view) Author: Chuck Blake (cblake) Date: 2001-12-17 03:46
posixmodule.c and configure have several provisions to
make st_rdev, st_blocks, and st_blksize accessible if
the host system supports them.

Unfortunately, the length of the returned stat tuple
does not reflect this.  The fix is trivial -- replace 
a literal "10" with 1 + the highest index macro.

That fix makes all detectable fields accessible, but
it may be that configure only discovers support for
some of the fields in which case it is impossible to 
decide which of the last couple elements refer to which 
fields.  E.g if configure only finds st_rdev there is
no way for a running program to easily know that.

In any event we surely want ST_RDEV fields, etc. as for
the rest of the stat fields (for consistency, if
nothing else).  The simplest fix is to have the posix 
module itself define the ST_RDEV and friends slot name 
variables.  Then the stat module can simply try to take 
them from the "os" module.

I'm submitting a patch which does all these things.
In particular I have a very nice categorical,
colorizing "ls" written purely in 500 lines of Python,
but it cannot do long listings for device files since
the st_rdev just isn't there.  Also "du" in Python
would fail in the presence of sparse files since 
st_blocks is missing.  These fields have been around
forever.  It's about time we actually get the support
working.

Long term it would probably be best if the "os/posix" 
module defined the variables that the stat module 
currently does.  This would simplify any portability 
issues since the C code can just use the configure 
macros.  For backward compatibility a stat module could 
remain that just imported all the correct names from 
the os module.
msg38489 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-12-17 04:29
Logged In: YES 
user_id=6380

Sorry, you have misunderstood the stat interface. For
historic reasons, the tuple size can't vary depending on
whether the platform supports certain fields -- there is too
much code out there that unpacks the tuple into exactly 10
local variables.

Instead, in Python 2.2 and later, you can access the fields
by name, and then you get access to all fields that exist.
We well be deprecating the tuple style access, and the
ST_XXX constants will go away (in Python 3.0 :-).

Example:

>>> import os
>>> x = os.stat("/")
>>> x.st_rdev
775
>>> x.st_blocks
8
>>> x.st_blksize
4096
>>> 
History
Date User Action Args
2022-04-10 16:04:47adminsetgithub: 35764
2001-12-17 03:46:53cblakecreate