Just discussed with python developer in https://bugs.python.org/issue35914.
Starting from #15429, the return of some operators starts to switch from tuple to structseq. Object of structseq is not a tuple on python version < 3.2. Making structseq a subtype of tuple is an enhancement rather than a bugfix for python, so old python versions would never get that feature.
This results in compatibility issue that all user codes that rely on tuple check would fail on these python versions, examples are:
a = tensor.max(dim=0)
if isinstance(a, tuple):
print("I am a tuple")
Also in our code, there are many places that rely on PyTuple_Check, which would also fail on structseq. Currently, we are doing a workaround by creating six::isTuple and _six.is_tuple, to replace failed tuple checks discovered by unit tests. But there are still many tuple checks not handling structseq yet, as discussed in #15429 (comment), which might lead to strange behaviors.
cc: @apaszke
Just discussed with python developer in https://bugs.python.org/issue35914.
Starting from #15429, the return of some operators starts to switch from tuple to structseq. Object of structseq is not a tuple on python version < 3.2. Making structseq a subtype of tuple is an enhancement rather than a bugfix for python, so old python versions would never get that feature.
This results in compatibility issue that all user codes that rely on tuple check would fail on these python versions, examples are:
Also in our code, there are many places that rely on
PyTuple_Check, which would also fail on structseq. Currently, we are doing a workaround by creatingsix::isTupleand_six.is_tuple, to replace failed tuple checks discovered by unit tests. But there are still many tuple checks not handling structseq yet, as discussed in #15429 (comment), which might lead to strange behaviors.cc: @apaszke