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
_getfileinformation
forkpty
getloadavg
getresgid
getresuid
openpty
os2_error (can't get excited about this one)
pipe, pipe2
times
uname
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?

+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.)

> 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?)

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?

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?

Whoops, here's the patch.

New changeset 460407f35aa9 by Larry Hastings in branch 'default':
Issue #15118: Change return value of os.uname() and os.times() from
http://hg.python.org/cpython/rev/460407f35aa9

Yummy!