> What IS unprecedented is having a C function bend over backwards to return an instance of collections.namedtuple().  

Is this an issue that anyone is currently insisting upon? From what I can tell the current implementation uses a structseq and none of my objections had to do with the properties of a structseq.

> ISTM the cross-version pickling issue is minor red herring.  We've cheerfully upgraded tuples to structseqs on a number of occasions and it hasn't been an issue.

I generally agree with this - it is nice to not break this compatibility when there's no good reason to do so, but pickling data in one version of Python and unpickling it in another is not something that's supported by the pickle module anyway.

> Tim, would you please weigh in on this so we can put this to bed, either closing the request because we're too meek to make any change, 
upgrading to structseq to provide the requested functionality, or twisting our code in weird ways to have a C function become dependent on a pure python module.

I must take some umbrage at this framing of the question. I don't even know where meekness comes into it - adding *any* new functionality brings support burdens and additional code complexity and changes to code that's been stable for a long time like `dateutil.isocalendar` is particularly likely to cause breakages if only because of the time people have had to start relying on the specific implementation. I have merely asked for a justification and an argument other than your subjective judgement that this is a nice improvement.