New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uname and other os functions should return a struct sequence instead of a tuple #59323
Comments
The trend in the standard library is to get rid of awkward Python-1-style tuple return values and switch to struct sequences. (And perhaps, in the fullness of time, to deprecate the iterability of such objects. But that's for the future.) os.stat is a good example; it's much better to say s = os.stat() then refer to s.st_mtime than s[5] (or whatever the offset is). And doing destructuring assignment... ptui! I just noticed that the following functions in Modules/posixmodule.c still use BuildValue to build raw tuples: _getdiskusage I think it'd be worthwhile to change all of these to struct sequences, sooner or later. I realize we're almost out of time for 3.3, but perhaps we could hit the important ones (uname! times!) and get to the rest for 3.4? |
+1. |
os._getdiskusage is an internal helper for shutil.getdiskusage on Windows, which does return a named tuple. The private C function can continue returning a tuple IMO. +1 on changing uname for 3.3! No opinion on times; I don’t use it and don’t understand the member names anyway :) |
Agree for changing times() and uname(). But functions that return a 2- or 3-element tuple, which immediately will be unpacked, no need to change. Keep it simple. |
Patch implementing struct sequences for os.uname() and os.times(). Those two are a slam dunk, so let's try and get 'em into 3.3. Patch includes docs! Maybe it's ready! Who knows! |
(OT, but since you brought it up: In my opinion, deprecating the iterability of any builtin class is a horrible idea. It is a Python feature, especially in 3.x, that all *are* iterable. However, I would agree that named tuples should be iterable by name-object pairs, just like dicts. Position is not the real key.) |
As you say, OT. But I don't see how it's a feature. Destructuring assignment is opaque (what was the order of fields again?), and with named attributes almost always unnecessary. And I find it hard to believe that there's a good use case for iterating over the values in a loop. I don't propose deprecating the iterability of these structures simply because I think it's inappropriate in a point release. But I hope to remove that misfeature in Python 4. (If you wish to continue the discussion, perhaps we should take it somewhere else?) |
Okay, this patch is definitely ready. Changes from the last patch:
Of course, with the patch applied python passes the entire regression test suite. (Of course!) Can I get a review? |
Whoops, here's the patch. |
New changeset 460407f35aa9 by Larry Hastings in branch 'default': |
Yummy! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: