Paul Ganssle <p.gans...@gmail.com> added the comment:

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

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue24416>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to