Author lemburg
Recipients brian.curtin, eric.smith, lemburg
Date 2010-01-26.10:07:55
SpamBayes Score 6.89633e-07
Marked as misclassified No
Message-id <>
In-reply-to <>
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 Maybe we should add a parameter named something like "level", defaulting to 0.
> 0 = existing behavior, but with named tuple
> 1 = return named 9-tuple OSVERSIONINFOEX values
> other values: reserved for future use
> Or maybe we should make it a bool instead, and not worry about future expansion.

The usual approach to such problems is keeping the number of tuple
items and their order the same and only add new items as additional
attributes to the struct.

See the CodecInfo tuple in for an example on how this is
done. The tuple is still a 4-tuple, but it provides access to more
items via named attributes.
Date User Action Args
2010-01-26 10:07:57lemburgsetrecipients: + lemburg, eric.smith, brian.curtin
2010-01-26 10:07:56lemburglinkissue7766 messages
2010-01-26 10:07:55lemburgcreate