[issue7766] sys.getwindowsversion as PyStructSequence

Brian Curtin added the comment: Yep, setting this back to closed. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-lis

[issue7766] sys.getwindowsversion as PyStructSequence

Marc-Andre Lemburg added the comment: Brian Curtin wrote: > > Brian Curtin added the comment: > > The previously mentioned comments about backwards incompatibility with the > number of items in the sequence are now a problem, since structseq now > inherits from tuple. It seems that n_in_seq

[issue7766] sys.getwindowsversion as PyStructSequence

Brian Curtin added the comment: The previously mentioned comments about backwards incompatibility with the number of items in the sequence are now a problem, since structseq now inherits from tuple. It seems that n_in_sequence gets ignored and we have a 9 item tuple. -- status: closed

[issue7766] sys.getwindowsversion as PyStructSequence

Eric Smith added the comment: Committed in trunk r77763, in py3k r77765. -- assignee: -> eric.smith resolution: -> accepted stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue7766] sys.getwindowsversion as PyStructSequence

Eric Smith added the comment: Here's the final version of the patch. After some testing on various platforms I'll commit it. -- Added file: http://bugs.python.org/file16020/winver_as_structseq_ex4.diff ___ Python tracker

[issue7766] sys.getwindowsversion as PyStructSequence

Eric Smith added the comment: I can confirm the most recent patch (ex2) doesn't break anything on MacOS or Linux. It's clear that structseq.c is designed to be used this way, with more named members than unnamed members (and vice-versa, actually). See n_members vs. n_in_sequence in Objects/s

[issue7766] sys.getwindowsversion as PyStructSequence

Brian Curtin added the comment: Thanks a lot for taking a look at this, Eric and Marc-Andre. Apologies for the few mistakes in there, I jumped the gun and submitted that last patch before having run the full test suite again. Good catch on the missing #ifdef. I will also run this on Mac and L

[issue7766] sys.getwindowsversion as PyStructSequence

Eric Smith added the comment: Here's a patch that implement's Marc-Andre's suggestion. The docstring and documentation need work. I still need to verify that this isn't a misuse of PyStructSequence, but the tests pass on Windows. I need to verify a few other platforms to make sure the #ifdef

[issue7766] sys.getwindowsversion as PyStructSequence

Marc-Andre Lemburg added the comment: Eric Smith wrote: > > Eric Smith added the comment: > > Great idea, Marc-Andre. I agree that's the better approach. > > It looks like PyStructSequence supports this, by setting n_in_sequence to a > value smaller then the number of PyStructSequence_Field

[issue7766] sys.getwindowsversion as PyStructSequence

Eric Smith added the comment: Great idea, Marc-Andre. I agree that's the better approach. It looks like PyStructSequence supports this, by setting n_in_sequence to a value smaller then the number of PyStructSequence_Fields. A quick look doesn't show any uses of this in the C code (except mayb

[issue7766] sys.getwindowsversion as PyStructSequence

Marc-Andre Lemburg added the comment: Eric Smith wrote: > > Eric Smith added the comment: > > The more I think about this, the more concerned I am about changing the > number of elements in the tuple. That's the change that broke platform.py. > Maybe we should add a parameter named somethin

[issue7766] sys.getwindowsversion as PyStructSequence

Eric Smith added the comment: The more I think about this, the more concerned I am about changing the number of elements in the tuple. That's the change that broke platform.py. Maybe we should add a parameter named something like "level", defaulting to 0. 0 = existing behavior, but with named

[issue7766] sys.getwindowsversion as PyStructSequence

Eric Smith added the comment: Here's an updated patch. I fixed some docstrings, modified it to work with the most recent assertIsInstance changes, and added #ifdef for Windows. There are a number of test failures still, I think all of them relating to errors in platform.py where it calls sys.

[issue7766] sys.getwindowsversion as PyStructSequence

Brian Curtin added the comment: Good point about OSVERSIONINFOEX. I've actually wanted some of that info as well, and according to MSDN the minimum supported client to get that structure is Windows 2000 - same as OSVERSIONINFO. Attached is a patch updated with your comments plus the use of OS

[issue7766] sys.getwindowsversion as PyStructSequence

Eric Smith added the comment: I like this. I've visually reviewed the patch, but haven't tested it yet. I'm willing to commit this. Could you add to the tests to assert that .major is equal to [0], etc.? Also, the documentation says that element [4] is "text", but you've referred to it as "s

[issue7766] sys.getwindowsversion as PyStructSequence

New submission from Brian Curtin : I always find myself wishing sys.getwindowsversion() utilized the named tuple concept, so here it is against trunk. sys.version_info was also changed in this manner for 2.7. Because it is a PyStructSeq/named tuple, it is still accessible like a regular old t