[Patches] [ python-Patches-462296 ] Add attributes to os.stat results
noreply@sourceforge.net
noreply@sourceforge.net
Mon, 17 Sep 2001 15:53:56 -0700
Patches item #462296, was opened at 2001-09-17 10:57
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Mathewson (nickm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add attributes to os.stat results
Initial Comment:
See bug #111481, and PEP 0042. Both suggest that the
return values for os.{stat,lstat,statvfs,fstatvfs}
ought to be struct-like objects rather than simple tuples.
With this patch, the os module will modify the
aformentioned functions so that their results still
obey the previous tuple protocol, but now have
read-only attributes as well. In other words,
"os.stat('filename')[0]" is now synonymous with
"os.stat('filename').st_mode.
The patch also modifies test_os.py to test the new
behavior.
In order to prevent old code from breaking, these new
return types extend tuple. They also use the new
attribute descriptor interface. (Thanks for
PEP-025[23], Guido!)
Backward compatibility: Code will only break if it
assumes that type(os.stat(...)) == TupleType, or if it
assumes that os.stat(...) has no attributes beyond
those defined in tuple.
----------------------------------------------------------------------
>Comment By: Nick Mathewson (nickm)
Date: 2001-09-17 15:53
Message:
Logged In: YES
user_id=499
Martin: I'm not entirely sure what you mean here; while my
patch for extra fields requires a minor chunk of C (to
access the struct fields), the rest still works in pure
python. I'm attaching this second version for reference.
I'm not sure it makes much sense to do this with pure C; it
would certainly take a lot more code, with little benefit I
can descern. But you're more experienced than I; what am I
missing?
I agree that the field naming is suboptimal; I was taking my
lead from the stat and statvfs modules. If people prefer,
we can name the fields whatever we like.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-09-17 15:24
Message:
Logged In: YES
user_id=21627
I second the request for supporting additional fields
where available. At the same time, it appears
unimplementable using pure Python.
Consequently, I'd like to see this patch redone in C. The
implementation strategy could probably remain the same,
i.e. inherit from tuple for best compatibility; add the
remaining fields as slots. It may be reasonable to
implement attribute access using a custom getattr
function, though.
I have also my doubts about the naming of the fields. The
st_ prefix originates from the time where struct fields
were living in the global namespace (i.e. across different
structures), so prefixing them for uniqueness was
essential. I'm not sure whether we should inherit this
into Python...
----------------------------------------------------------------------
Comment By: Nick Mathewson (nickm)
Date: 2001-09-17 13:58
Message:
Logged In: YES
user_id=499
BTW, if this gets in, I have another patch that adds support
for st_blksize, st_blocks, and st_rdev on platforms that
support them. It don't expose these new fields in the
tuple, as that would break all the old code that tries to
unpack all the fields of the tuple. Instead, these fields
are only accessible as attributes.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470