Message334965
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. |
|
Date |
User |
Action |
Args |
2019-02-06 17:53:07 | eric.snow | set | recipients:
+ eric.snow, rhettinger, christian.heimes, benjamin.peterson, Xiang Gao |
2019-02-06 17:53:05 | eric.snow | set | messageid: <1549475585.45.0.911660545789.issue35914@roundup.psfhosted.org> |
2019-02-06 17:53:05 | eric.snow | link | issue35914 messages |
2019-02-06 17:53:05 | eric.snow | create | |
|