Kyle Gorman
Kyle Gorman
I did some research and the issue in question is PyTorch-Lightning. Presumably once we migrate onto >= 2.0.0 as per #60, we can release the pin.
> Could you link to an example in the codebase? A good example are the two classes [here](https://github.com/CUNY-CL/yoyodyne/blob/master/yoyodyne/data/batches.py).
Okay the code in `batches.py` is an example of the solution. For an example of where this would be a problem of sorts, we have return types like `Tuple[torch.Tensor, Tuple[torch.Tensor,...
A lightweight alternative is to just declare a particular type and not a class. That'd be better than nothing. I agree that HF went too far.
> I am not sure I follow. Is there a convention in python for defining types that are not classes? Does this refer JUST to the typing annotation stuff? Yes...
> > we have return types like Tuple[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]] in the LSTM encoder [here](https://github.com/CUNY-CL/yoyodyne/blob/master/yoyodyne/models/modules/lstm.py#L64), > > Just a note, that typing hint is just out-of-date. That Module returns `ModuleOutput`....
This was completed in #205.
When something doesn't pickle yet you usually can just give it the necessary methods, but I don't want to hack into TQDM so I think the hacky solution is fine.
Yeah that sounds like a Johns Hopkins PhD dissertation ;)
> Am I missing a reference for the JHU? no it just used to be the home of this sort of thing