Eric Snow <ericsnowcurren...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue35914> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
