sys.version_info is just asking for a named tuple consisting of major,minor, micro, releaselevel, and serial.This is assuming, of course, that bootstrapping doesn't get in the way.

I concur that bootstrapping may be a problem. Using a NamedTuple alsoincreases the number of loaded modules by 4 (_collections.so, keyword.pyand operator.so).But we could reimplement it with a PyStructSequence like I did forsys.float_info. It's straight forward and easy to implement with theexample code in Object/floatobject.c:PyFloat_GetInfo().

Hello, my name is Ross Light.  I've written a patch for this, but thisis my first patch, so someone please review.This does pass all regression tests, but I did have to modify thetest_sys case to not check for sys.version_info being a tuple.

You also need to add unit tests for the new behavior you've implemented.

Oh yes, you're right.  Sorry!

+1 on this idea

A couple of further comments:- please use tabs for indentation consistently.- please changeDoc/library/sys.rst, including adding a versionchangedindication- I find the naming of the macros *Flag confusing; to me, a "flag" says"boolean" - but I'm not a native speaker (of English). Common names are"item", "field", "element".

Okay, here's a patch with the requested changes.  You're right in sayingthat flag is usually boolean, I was just going along with several otherfiles where there's float and int flags (i.e. floatobject.c).

Rather than deleting the isinstance() check from the tests completely, Isuggest changing it to be:self.assert_(isinstance(vi[:], tuple))Also, comparing directly with a tuple is also a fairly common use ofversion_info so it would be worth adding a test to explicitly guaranteethat comparison:self.assert_(vi > (1,0,0))Patch applied and built cleanly for me, but I haven't checked the docbuild yet.

Tests added and new patch uploaded.  Anything else, anyone?

The doc string for sys includes:version_info -- version information as a tupleI'm not sure changing this to "... as a structseq" makes it any moreuseful, but it's more correct. Does anyone have a preference? I'd usethe same wording as float_info, but that's missing from the doc string(and I'll deal with that as a separate issue).Other than that, this all looks good to me. I also tested that the docsbuild. I'll check it in once I get or invent new wording for the doc string.

On Wed, Feb 4, 2009 at 05:56, Eric Smith <report@bugs.python.org> wrote:>> Eric Smith <eric@trueblade.com> added the comment:>> The doc string for sys includes:> version_info -- version information as a tuple>> I'm not sure changing this to "... as a structseq" makes it any more> useful, but it's more correct. Does anyone have a preference?Does "... as a named tuple" make sense?-Brett

"... as a named tuple" works for me. I'll go with that. Thanks!

Technically it's not a named tuple. Calling it named tuple may causeconfusing.http://docs.python.org/library/os.html#os.stat calls it astructure.

> Eric Smith <eric@trueblade.com> added the comment:> "... as a named tuple" works for me. I'll go with that. Thanks!+1 Remember, "named tuple" is a concept, not a class.  It is anything thatprovides attribute access as an alternative to indexed access (see thedefinition in the glossary where time.struct_time is given as anexample).  Running the collections.named_tuple() factory functioncreates a new class with named tuple features, but it is just one ofseveral ways of creating named tuples.

Committed inr69331 (trunk) andr69346 (py3k).