Title: uname and other os functions should return a struct sequence instead of a tuple
Type: behavior Stage: resolved
Components: Versions: Python 3.3, Python 3.4
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: larry Nosy List: Arfrever, eric.araujo, georg.brandl, hynek, jcea, larry, python-dev, serhiy.storchaka, terry.reedy
Priority: normal Keywords: patch

Created on 2012-06-20 20:12 by larry, last changed 2012-06-24 11:35 by larry. This issue is now closed.

File name Uploaded Description Edit
larry.uname.and.times.structseq.1.diff larry, 2012-06-21 09:52 First patch, adding structseq for os.uname() and os.times(). review
larry.uname.and.times.structseq.2.diff larry, 2012-06-24 01:38 review
larry.uname.and.times.structseq.3.diff larry, 2012-06-24 05:22 Third patch, chock full of nutritious vitamins. Just the thing a growing snake needs. review
Messages (12)
msg163295 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2012-06-20 20:12
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:

os2_error (can't get excited about this one)
pipe, pipe2
wait, waitpid
wait3, wait4 (but one of the values is a struct sequence)

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?
msg163301 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2012-06-21 00:29
msg163302 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-06-21 03:24
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 :)
msg163304 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-06-21 05:41
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.
msg163317 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2012-06-21 09:52
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!
msg163537 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-06-23 07:10
(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.)
msg163609 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2012-06-23 13:45
> 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.

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?)
msg163698 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2012-06-24 01:38
Okay, this patch is definitely ready.  Changes from the last patch:
* The two return types are now exposed in the os module (os.uname_result
  and os.times_result) and are permanently on even if os.uname() or
  os.times() are not available.
* I updated the library to use the field names where appropriate.
  Fun trivia: there are no uses of os.times() in the library--not even
  in the regression test suite.

Of course, with the patch applied python passes the entire regression test suite.  (Of course!)

Can I get a review?
msg163714 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2012-06-24 05:21
Attached is patch #3.  Ned Deily advised me not to touch distutils, and packaging is in the process of being removed.  So I backed out of my changes to those two packages.  Apart from that the patch is the same as #2.

Georg: mind if this goes in before freeze?
msg163715 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2012-06-24 05:22
Whoops, here's the patch.
msg163774 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-06-24 11:33
New changeset 460407f35aa9 by Larry Hastings in branch 'default':
Issue #15118: Change return value of os.uname() and os.times() from
msg163775 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2012-06-24 11:35
Date User Action Args
2012-06-24 11:35:14larrysetstatus: open -> closed
resolution: fixed
messages: + msg163775

stage: patch review -> resolved
2012-06-24 11:33:47python-devsetnosy: + python-dev
messages: + msg163774
2012-06-24 08:37:35hyneksetnosy: + hynek
2012-06-24 06:08:20larrysetassignee: larry
type: behavior
stage: patch review
2012-06-24 05:22:25larrysetfiles: + larry.uname.and.times.structseq.3.diff

messages: + msg163715
2012-06-24 05:21:41larrysetnosy: + georg.brandl
messages: + msg163714
2012-06-24 01:38:10larrysetfiles: + larry.uname.and.times.structseq.2.diff

messages: + msg163698
2012-06-23 13:45:01larrysetmessages: + msg163609
2012-06-23 07:10:14terry.reedysetnosy: + terry.reedy
messages: + msg163537
2012-06-21 09:52:05larrysetfiles: + larry.uname.and.times.structseq.1.diff
keywords: + patch
messages: + msg163317
2012-06-21 05:41:30serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg163304
2012-06-21 03:24:02eric.araujosetnosy: + eric.araujo
title: uname &c should return a struct sequence instead of a tuple -> uname and other os functions should return a struct sequence instead of a tuple
messages: + msg163302

versions: + Python 3.3, Python 3.4
2012-06-21 00:29:46jceasetnosy: + jcea
messages: + msg163301
2012-06-20 20:16:27Arfreversetnosy: + Arfrever
2012-06-20 20:12:40larrycreate