Fix python 3.7 and PL==1.4.0 compatibility bugs

[lebrice]

• Limit pytorch version to 1.8.X, from >= 1.8: PyTorch suddenly got
  really picky about type annotations on subclasses of IterableDataset
  for some unexplained reason, and that breaks most of the
  EnvDataset-related wrappers in Sequoia.

• Fix compatibility issues with lru_cache taking one required argument
  in python 3.7

• Fix PyTorch-Lightning==1.4.0 compatibility issues due to ModelSummary
  not having a MODE_DEFAULT anymore

• Fix typing.get_origin bug with python 3.7 in typed_dict.py

Signed-off-by: Fabrice Normandin fabrice.normandin@gmail.com

[ejguan]

Hey @lebrice,
Just got a notice of the issue related to IterableDataset. We did introduced a typing system for IterableDataset due to a new design of DataLoader. We want to use the type annotation as a Dataset attribute to enable the lazy data loading. And, it did make IterableDataset having more strict requirements. But, since we are relying on the python typing to do the type evaluation, the same Error should be raised from any static type checker like mypy.
We are sorry that it prevents you to upgrade PyTorch to 1.9, do you mind sharing some examples to us (may be file an issue on GitHub) about the Error? Then, we can provide suggestion or fix bugs from our side.

[lebrice]

Hi @ejguan, thanks for reaching out!

Do you have a link to the documentation or rationale behind that change? Id like to learn more about this.

My current (uninformed) opinion is that this is probably the least pythonic thing I've ever come across, but I'm also open to being very wrong about this! 😛

[ejguan]

We have a general RFC for new DataLoader and IterDataPipe (alias of IterableDataset). pytorch/pytorch#49440
We want to make DataPipe modular and connecting each DataPipe instance into a graph to represent a Dataset. And, each DataPipe represents a function like shuffling, batching, loading from disk. But, to validate the prior DataPipe and construct DataPipe instance without loading the data from prior DataPipe, we need a way to figure the type of data from prior DataPipe. For example, unzip DataPipe needs to know the number of elements for each data from prior DataPipe, then construct corresponding unzipped DataPipe.

class Unzip(IterDataPipe):
    def __new__(self, datapipe):
        num = len(datapipe.type)
        ...
        return tuple(SplitDataPipe(self, n) for n in range(num))

And, the typing system for DataPipe does have a document here https://github.com/pytorch/pytorch/blob/master/torch/utils/data/typing.ipynb
Let me know you thought. Any feedback is appreciated.

[lebrice]

Hey @ejguan this looks very interesting! I'll take a closer look, and in the meantime I've created a new issue for this: #235 .

Thanks again for reaching out! :)