[issue35914] [2.7] PyStructSequence objects not behaving like nametuple

[Eric Snow]

Eric Snow <ericsnowcurrently at gmail.com> added the comment:

tl;dr It's too late to change anything here.  Also, is it actually a problem in practice?

----

At this point enhancements can not go into 2.7 (you're welcome to appeal to the release manager).  The changes to `PyStructSequence` (from bpo-1820) appear to have been merged for 3.2 in July 2010.  However, this is just after 2.7 went final and 3 months after the first beta release (where no more enhancements are allowed).

Likewise, at this point we cannot revert the original change (from bpo-1820).  Doing so in 3.7 (the only one taking bug fixes) or 3.8 (upcoming) would break compatibility with 3.2 and up.

Notably, this discrepancy has been there since 2.7/3.2 were released (8+ years).  I don't recall any previous reports of a problem here, so I expect the impact is small.

Regardless, from what I understand the problem is that pytorch was returning tuples and (with that PR) was going to return "named" tuples. 
 For C-extension functions it wouldn't actually be a tuple any more but a structseq instead.  So user code that checked for a tuple would suddenly work differently.  Is that right?

If so, I'm not clear on when this would be a problem in practice.  Why would users of pytorch (or any similar library) be checking the type returned from a specific function in the library's documented API?  If it was returning a tuple before then I'd expect them to be using unpacking or index access.  That would keep working if the library switched to namedtuple and structseq.

----------
nosy: +benjamin.peterson, christian.heimes, eric.snow, rhettinger
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35914>
_______________________________________